Practical GrapheneOS for the Paranoid • Ventral Digital
February 8, 2025•11,166 words
Clip source: https://ventral.digital/posts/2024/12/9/practical-grapheneos-for-the-paranoid/
GrapheneOS (opens in a new tab) is a FOSS (Free and Open Source Software) Operating System based on the Android Open Source Project (AOSP) (opens in a new tab), specifically focusing on improving privacy and security. Although we'd all like to have the best security and best privacy possible, it's an unfortunate fact that such improvements rarely come without a cost to convenience and usability. Here, we will explore how to get the most out of Graphene's improvements, and the impact of these measures on the user experience with practical solutions.
Probably the most common question by those looking into the GrapheneOS project for the first time is: Why are only so few devices officially supported, and why the heck are all of them expensive Pixel phones made by evil Google?
Technically, there currently simply isn't another reasonable choice.[183] Just to be clear, GrapheneOS does not have contractual exclusivity for Google's devices[186], and neither are Pixels incredibly secure, it's rather that all the alternatives are downright awful.[167] The GrapheneOS project maintains a list of (non-exhaustive) requirements (opens in a new tab) that they have for current and future officially supported devices[64][65] and, unfortunately, at this time only Pixels are able to meet them.
Pixel devices have first-class support for alternate operating systems[59], likely thanks to the fact that they serve as a reference for Android development.[134] They receive proper regular updates of their firmware[64], and offer advanced hardware security features such as memory tagging[64][167] which remain available even when non-stock operating systems are installed on them.[181]
Most other OEMs on the other hand merely offer half-baked, partially working support for alternative operating systems, as they see it as a non-production hobbyist feature.[134] Heck, most of them completely skip basic security features and don't bother providing proper updates.[64] To make matters even worse, they often add lots of complexity and, with it, attack surface, with their overall changes to the system.[92]
In the past, GrapheneOS has attempted partnering with OEMs but it turns out to be incredibly hard to make a device with comparable security to a Pixel. Although these partnerships fell through in the end, the GrapheneOS project still hopes to find a hardware company capable of manufacturing devices able to comply with Graphene's security requirements in the future.[141]
The only Android OEM even close to Pixel devices in terms of hardware security is Samsung.[92] They have even partnered up with Google to improve device security, with some success[126], but in the end Samsung still tends to lag behind by 2-3 years in shipping the new security features introduced by Pixels.[180] While Samsung is theoretically only missing a couple of the requirements, they still lack serious alternate OS support[59][64], which prevents GrapheneOS from using even those features that it has.[65]
Broad device support would currently imply being available to very badly secured devices, unable to support many of Graphene's security features. It would also take away a substantial amount of resources from their work on privacy and security, due to a lot of it being rather hardware-specific.[123][280] However, if there were other devices complying with the requirements, the GrapheneOS project would certainly plan to support them.[155]
There are various alternate operating systems for Android devices with a focus on privacy and security, or at least a broader support of devices. Though, according to the GrapheneOS project, none of these can truly be considered viable alternatives.
The most basic critique the GrapheneOS team levies against pretty much all of them is the great delay and, in some cases, even complete omission of important security patches that users of the purely open source variant of Android (AOSP) would enjoy.[92][172]
LineageOS (opens in a new tab) is one of these offenders, though granted, this project's focus is device longevity and broad compatibility rather than security[144]. It's critically lacking verified boot, making it trivial to break into with physical access.[172] The /e/OS (opens in a new tab) project markets itself as fully "deGoogled" mobile ecosystem focusing on privacy while building upon Lineage's shaky foundation[90]. The e/OS comes bundled with applications and services that give users a questionable feeling of privacy while these services themselves are arguably invasive.[159]
Graphene's possibly greatest "competitor", CalyxOS (opens in a new tab) is apparently not only regularly behind on patches but has also misled users about this with inaccurate Android security patch levels.[91][92] They furthermore implemented security features with serious flaws, such as the panic-wipe feature that didn't reliably delete incriminating data as intended.[122][296]
Then there is CopperheadOS (opens in a new tab), the name under which GrapheneOS was formerly known. I will not go into detail on the drama behind the hostile takeover and eventual separation from the company that was intended to financially sponsor the project. It's noteworthy to mention though that this company now sells CopperheadOS as closed source fork.[184]
Finally Purism (opens in a new tab) with their custom, optionally Made-In-USA, hardware that promises control over your privacy with features such as (questionable?[161]) hardware switches. The GrapheneOS team strongly disagrees with the choice of hardware security components made for their devices and also with the convoluted process required for firmware and microcode updates.[140] Their Librem 5 device is nearly entirely closed source hardware and firmware[215] though many people have been misled to believe the opposite to be true.[88]
GrapheneOS accuses these projects of empty marketing with buzzwords that mislead users into trusting both outdated and vulnerable soft- and hardware.[93][121][140] They even go so far as to say that users would be better off using an iPhone (in Lockdown mode[194]) instead of any of the mentioned projects as the next best option for privacy and security after GrapheneOS.[89][92][125][126][191]
Don't misunderstand, the GrapheneOS project does by no means claim that its operating system is impenetrable[168][199], but it does focus on substance rather than branding and marketing. This becomes quite clear when comparing Graphene's website (opens in a new tab) to those of other projects: GrapheneOS is an unapologetically technical project which I personally greatly appreciate as it saves me from having to dig through marketing to find the technical facts.[245] On the other hand, I can certainly see how this is rather intimidating to the average user.
We've covered that GrapheneOS currently only supports Pixel devices due to those being the only ones having sufficient hardware security measures in place. All well and good, but wouldn't that be pointless if those devices are backdoored?
As mentioned, Google's Pixels serve as reference devices for Android development, causing many experts to work with them.[134] Furthermore, Google has been very open to external security research, thanks to which Pixels have received great security research attention.[212] It would be arguably difficult to hide backdoors within the devices under these circumstances.
Another argument is that it would be far easier to attack the supply chains of tiny companies that outsource their manufacturing rather than compromise the global production of iPhone or Pixel devices without discovery. Users of such mainstream devices benefit from a lot of scrutiny that these devices receive.[179] It's also worth noting that leaks from forensic firms, that specialize in breaking into smartphones and are often hired by governments, do not offer any evidence for the existence of purposefully placed backdoors either.[198][199]
Still, some argue against using anything made by Google out of principle. For the best chances to achieve this, they'd have to make use of Apple's products though, due to Google playing a huge part in the development of many open-source projects, including the Linux kernel itself.[182] The mission of GrapheneOS is not entirely centered around the idea of avoiding one particular company by any means necessary, rather it's to obtain the best possible privacy with the best possible tools available.[159]
For the best security, using a Pixel of the 8th or 9th generation is strongly recommended.[191][280] They are considered significantly more secure thanks to the hardware features that GrapheneOS can make use of, such as memory tagging.[169] The 9th generation comes with an additionally hardened[56] and more efficient cellular radio, so if you are planning to use it with a SIM card you can expect improved security and battery life.[66] The Pixel 9 Pros come with 16GB of RAM which will be especially useful if you're planning to use GrapheneOS with multiple user profiles (benefits of which will be explained later).[124]
The 9th generation is currently also ahead in terms of the hardened Linux kernel used, but the 8th generation is likely to be upgraded soon making both generations very similar in terms of security.[170] With that in mind, a Pixel 8a phone will be the ideal budget device with some trade-offs in performance. Either way, both generations are receiving 7 years of full support.[62]
Pixel devices of the 6th and 7th generation still have a few years of support left, making them a decent choice if you already own one and want to keep using it for a while longer. This is not a recommendation for buying a new one of these generations though.[169] Also, keep in mind that there are various security features that GrapheneOS can only make use of with the hardware of newer generations.[57]
Anything older than that is considered End-Of-Life and the GrapheneOS project strongly recommends against continuing to use them[173], regardless of which operating system is used.[62] This is true even though GrapheneOS still provides extended support for some of them, which is merely intended for harm reduction to buy users some time to migrate to a fully supported device.[280] For example, there no longer are firmware patches and driver support for the Pixel 5a[100], and there's even a known, unpatched remote code execution vulnerability that could be exploited to take control of the device.[83]
There are companies selling Pixel devices with GrapheneOS preinstalled, but there are also some that claim or wrongly suggest that the operating system installed is GrapheneOS or using parts of it.[87] Additionally, there's a chance that such preinstall- or used devices have been tampered with.[86]
GrapheneOS is not affiliated and does not endorse any of these companies and instead recommends buying a supported device and going through the installation process yourself.[291] Buying one at a local electronics store with cash will even allow you to do so anonymously.[125] Just make sure to avoid devices that are locked to a specific carrier.[213]
The easiest method to install GrapheneOS is using a compatible web browser on a compatible second device - that can be a chromium browser on a laptop or even on a second Android phone![267] You just need a cable to connect both devices. On the secondary device, you simply have to open the web installer (opens in a new tab) page and follow the instructions. Don't worry: Your device will not lose its warranty[132], it'll not get bricked[297], and if you don't like GrapheneOS you can always go back to stock Android.[298]
Assuming you are now a proud owner of a Pixel device with a fresh GrapheneOS installation, you might be surprised by the warning greeting you when the device is started. It'll disappear and continue booting GrapheneOS after a few seconds unless you press the power button to pause the screen. The string of characters shown following "ID:" is called the verified boot key fingerprint which is a cryptographic hash value that allows you to verify that the GrapheneOS version installed is authentic - and it should never change![235]
The fingerprints differ depending on the device model and the above list of them was copied from the web installer page (opens in a new tab).[222] Although unlikely, it's possible that the server infrastructure of the GrapheneOS project was compromised and that attackers have replaced both the operating system files used during installation and the list of key hashes. You can compare the fingerprint displayed on your device with the table above to ensure that you've installed a legitimate version of GrapheneOS.[267][235]
GrapheneOS comes bundled with the Auditor App. It's another way to validate the authenticity and integrity of the operating system to ensure that no tampering has occurred. You can execute a check manually with a second device that has the Auditor App installed. This does not need to be another GrapheneOS installation as you can find the app on Google's Play Store (opens in a new tab).[292]
This verification can be automated using the attestation.app (opens in a new tab) website which is part of the GrapheneOS project. After registering on the website and pairing your device you'll receive an email alert if the device fails to provide valid attestations in time.[292]
Sadly it's currently not possible to host your own remote attestation server as using it would require changes to the Auditor App.[299]
There are three fundamental aspects on how GrapheneOS defends itself against security vulnerabilities: It reduces the amount of "surface" (ie. active functionality/code) that is exposed to potential attackers, makes the exploitation of vulnerabilities as difficult as possible, and sandboxes (ie. isolates) components from each other to decrease the impact of a vulnerability being exploited. As such measures impact usability and device performance, GrapheneOS allows users to choose their own preferences via various toggles in the settings.[244][248]
User data is stored in an encrypted manner with a key that is derived from, among other things, your chosen screen lock-method. That these can't simply be bypassed using brute force is ensured by delays enforced by "secure element" hardware.[281] Thanks to this measure, even a random 6 digit PIN provides a high level of security. If you don't want to depend on the security of the secure element, you can make use of long passwords with up to 128 characters.[258]
Unlocking using a pattern was removed from GrapheneOS as it is essentially a much worse version of a PIN and encourages unsafe pattern choices.[177] Instead, you should use at least a 6 digit PIN and consider turning on the PIN scrambling feature which raises the difficulty of figuring out the combination by an observer, fingerprint marks or side channels.[257]
Fingerprint Unlock can be configured, though for best security you should consider restricting it to authentication within apps (ie. disabling 'Use for screen unlocking'). Recently, Graphene's 2-factor fingerprint unlock feature has been released which allows a fingerprint+PIN combination to be used as a secondary unlock method. With it, you're able to have both a strong encryption password as well as the convenience of quickly unlocking your phone - after a successful first unlock using the password.[45][304]
If you have an eSIM or especially a physical SIM, it makes sense to configure a SIM PIN - though it should preferably be a different one than the one used for unlocking.[177]
Lastly, GrapheneOS offers setting a duress password/PIN. Once set, using it anywhere where a unlocking password or PIN can be entered, even in secondary user profiles[24], will irreversibly wipe the device (and installed eSIMs).[260] When triggered, information required for decryption is deleted and the device will shut down. On the next boot an invalid filesystem is detected and the device can be set up again as if it had been factory reset.[23] Note that this does not wipe the encrypted data itself as that would take a long time and gives attackers an opportunity to interrupt the process.[24]
A freshly booted device that hasn't been unlocked yet has its user data still fully encrypted, or "at rest". Continued use after the first unlock often leads to unencrypted data accumulating in the device's ephemeral memory, which is something that forensic companies exploit. The Auto-Reboot feature was introduced as a protection against the extraction of unencrypted data.[48]
Although it's possible for applications to put sensitive data back to rest when the device locks, it's upon the developers to actually implement them that way - which rarely happens. Even the developers of the privacy-focused Signal messenger have shown little interest in implementing it, instead leaving it to forks like Molly to handle this in a better way. By automatically rebooting the device after some time, it is put back into a state of "before first unlock" (BFU).[49]
The reboot timer starts every time the device is locked and successfully unlocking it resets the timer. By default, the timer is set to 18 hours with the lowest, and most secure, option available at 10 minutes.[55] Note that the timer will only start if the device has been unlocked at least once since the last reboot.[259]
With the default value of 18 hours, the timer will be cancelled during consistent use to avoid impacting user experience. Due to GrapheneOS's very frequent updates requiring regular reboots in any case, this feature serves a secondary useful purpose.[73] If that still causes the device to reboot too often, the timer can be increased up to 78 hours or even completely disabled - though GrapheneOS strongly recommends against this.[44]
Note that if you're planning to use secondary user profiles, this feature may be particularly annoying as all user sessions will be ended and the device resets back to the default Owner user.[224]
When forensic companies attempt breaking into smartphones they typically prefer to do so via the USB interface which has a massive attack surface due to the many functions it offers.[54][128][176] Pixel devices offer hardware-level control over the USB-C port, a feature that isn't currently even used by the stock version of Android but a very important aspect to the GrapheneOS project.[181]
By default, GrapheneOS disables new USB-C connections as soon as the device is locked. In other words, you can plug in and use USB-C data while the device is unlocked, but once it's locked and you've pulled the plug it will reject new connections.[54][78] This measure includes disabling USB-C alternate modes such as DisplayPort.[249]
The most secure, though arguably also the most inconvenient, option available is to fully disable the USB-C port while the operating system is running. This will even prevent any vulnerabilities present in the power delivery logic of the device, but will also require it to be turned off in order to be charged.[55]
With USB out of the picture that leaves wireless attack vectors such as Wi-Fi, Bluetooth, and cellular. However, getting into a device from any of these will be much harder and more complex.[54] Isolation of hardware components has become the de-facto norm for mobile devices.[135] Pixels even have separate chips for each of these radios, and if you wanted you could remove the chips individually and the device would be able to continue to function.[178]
Although not yet enabled by default[69], you can set a timer to automatically turn off Wi-Fi and Bluetooth. The timer will begin once there's no longer an active connection. The GrapheneOS project is planning to extend this to NFC in the future as well.[55]
The issue of cellular connectivity is a lot more complex. First off, 5G, SMS, MMS, and Calls generally work as fine on GrapheneOS as they would with stock Android.[279] GrapheneOS adds various toggles that once again attempt to reduce the attack surface[195], though depending on your carrier, and the country you're in, you may have to play around with them to see what works.[40][116][117][223]
The GrapheneOS project recommends using the LTE-only toggle when possible.[275] LTE, which is sometimes referred to as 4G or 5Ge[279], is much more modern than the legacy 2G and 3G protocols, but also a lot less complex and more stable than the new 5G protocol.[209][129]. Note that, although it may make some forms of interception more difficult, the only intention of the LTE-only mode is disabling an enormous amount of code related to both these legacy and bleeding edge protocols.[275]
LTE and 5G do come with a form of encryption, but this is mostly intended for the protection of the network itself and not for the protection of your privacy.[275] No matter which mode you're using, you should avoid traditional phone calls and text using the cellular network, and instead use end-to-end encrypted messengers such as Signal and SimpleX. In fact, if you can, always prefer using Wi-Fi over cellular.[101][106][160]
The traditional telephone system is historically insecure and not designed with the goal of protecting user's privacy. You can imagine it like a walled garden where, once you've become a trusted party with access into it, you gain a significant amount of information and control over the network. This access can be bought for a few thousand USD per month and allows intercepting phone calls, SMS messages, and in some cases even roughly tracking someone's location. To do that an attacker needs your SIM card's unique IMSI identifier, but often it can be looked up simply by knowing your phone number. Using this the attacker would be able to intercept a 2-factor-authentication SMS while ensuring that your phone would not give any indication that such an SMS was ever sent to your number at all.[129][283][300]
When your phone authenticates with the cellular network it does so while providing information on both your SIM card and the device's cellular radio hardware. If you've bought both the phone and SIM anonymously, you're essentially using a persistent pseudonym. Since hardware information is being shared, replacing the SIM alone is not sufficient for a fresh identity.[96][125][127]
At this point, you might be considering using an external device, like a dedicated mobile hotspot, which would be much cheaper to regularly swap out together with a new SIM card. While this will increase your privacy, it will hurt your security as these devices typically have much worse hardware isolation and are way behind on security updates.[127] Compared to using the isolated internal radio of your Pixel, this will make it much easier for an attacker to gain control over the dedicated device, and if it is connected to your Pixel via USB this opens up a massive surface for attacking your phone.[99][128][135][176]
Some of these dedicated cellular devices allow spoofing the IMEI, ie. changing the hardware identifier to an arbitrary value. This would allow you to reuse the same dedicated device and simply change the IMEI value together with a new SIM card for obtaining a new identity on the network. You should know however that the IMEI is not the only hardware-specific identifier that cellular radios leak and, furthermore, there are ways to create "fingerprints" of these devices that could allow re-identifying them even with identifiers changed. In the worst case, you could even draw a lot of attention to yourself when the spoofing is too obvious.[96][97][98][128]
The GrapheneOS project does not recommend using a secondary device for cellular communication, but if you really want to do it then it would be better to use another Pixel device with GrapheneOS installed for it.[97] Note that if you're sharing cellular Internet via Wi-Fi, it's possible that someone nearby tracks your movements by tracking the signals of your Wi-Fi access point.[128]
Airplane mode is the only way to fully disable the cellular radio transmit, receive, and tracking capabilities of your device, and works appropriately on all Pixels. Once in airplane mode, Wi-Fi can be re-enabled and used without activating the cellular radio again.[106][283] If you intend to use your Pixel as a Wi-Fi-only device, you should consider removing the quick tile (the airplane-mode toggle visible when swiping down the status top-bar) so that you won't re-enable it by accident.[197]
You should be aware that cellular is not the only way carrier services can be used. Remember that there's Wi-Fi calling and texting. To prevent the SIM from authenticating with the carrier and using their network services via other Internet connections, you need to disable the SIM itself.[96][101][197]
Newer devices have special offline tracking systems intended to locate lost devices. GrapheneOS does not support and will not support these systems. If you want to be absolutely certain, you may consider keeping it within a faraday bag while you're not using it.[97][228]
It doesn't particularly matter whether you're using a data-only SIM card in terms of privacy, you're still authenticated to the cellular network. Not having texts and calls however does reduce attack surface for exploits. GrapheneOS may in the future add toggles to disable these capabilities to practically turn normal SIM cards into data-only equivalents.[171]
Using a VPN has no influence on carrier-based calls or texts. These functions will not go through the VPN even if you are using a Wi-Fi connection instead of cellular.[234]
Enabling the data-saver toggle will globally (ie. in all user profiles) stop apps from using cellular data in the background. Apps that use foreground services, meaning those apps that keep themselves running in the foreground via a permanent notification, are excluded from this restriction. Mobile data use can also be restricted per app.[196]
If you have no SIM card, and you are not in airplane mode, your device will still connect to the cellular network but it will not authenticate and should also not share any hardware identifiers. You will still be able to make emergency calls and receive emergency alerts. Note that making an emergency call will share radio identifiers of your device.[197]
Emergency alerts are sent out through the cellular network to all connected phones, even if it has no SIM. Normally, only airplane mode prevents receiving them.[95] Because GrapheneOS is not subject to typical regulations it provides toggles for turning off even alerts of "presidential" priority.[189]
So far we've discussed how to protect our device from outside threats, but it's just as important to ensure that none of the installed applications can take over from the inside. Apps on Android always run isolated within their own sandbox[233], limiting the resources they can access to those that they have been given permission for.[301] Malicious apps may request and use permissions for purposes unrelated to the app's core functionality, others may even attempt breaking out of their sandbox. Often the application itself is not even intentionally malicious at all but has a vulnerability or its supply chain is being attacked.[248]
Under App Exploit Protection you can find various measures that will increase the difficulty of an application breaking out of its sandbox. Many of them are not enabled for user-installed apps by default because they may cause those apps to crash or not work properly. But it's better to turn them on by default globally and then turn them off selectively for those apps that have trouble.[32][56]
There are other measures that are implicitly always turned on.[256] One of them is the use of ahead-of-time compilation instead of just-in-time compilation. This saves battery life, improves the performance of many apps and, generally, is another important security feature. It has a drawback though: App installations and updates will take a lot longer than on stock Android.[220][221]
In stock Android, permissions only exist for accessing the Camera, Microphone, Body Sensors, and Activity Recognition. Access to accelerometer, gyroscope, compass, barometer, thermometer, and any other sensors are simply given to apps by default without requiring any explicit consent. GrapheneOS adds a toggle to prevent access to these sensors being given by default. Since this too can cause crashes in applications that expect to receive valid data from these sensors, this measure is not active in a fresh GrapheneOS installation. Turning it on will notify you when apps attempted accessing such a sensor and you'll be able to selectively grant this permission according to your own judgment.[252]
Another permission that stock Android implicitly grants to all applications is access to networking functions. This includes device-local networking (localhost) which is currently a known way to bypass user profile isolation and allows apps of different profiles to communicate with each other. In GrapheneOS you'll be asked whether you want to grant this permission during the installation of an app. When the Network permission is not granted to an app, GrapheneOS pretends the network is down, which is usually handled by apps in a graceful manner.[252]
Just like you can disable app exploit protections on a per-app basis, you can take away permissions from apps according to your own judgment. Be careful to not remove any permissions from system apps that are installed by default though, as this can cause unforeseen issues.[230]
There are popular apps that demand rather invasive permissions such as access to all contacts or all files on the device. Graphene's scope functionality allows selecting a subset of contacts or files to which access is granted while the app in question will believe to have been given access to everything.[269]
By default, contact scopes act as if the contacts list is empty and users can then grant different kinds of access to specific contacts or groups of contacts.[255] Access to contacts is quite granular, allowing you to only share specific data with the app instead of the full contact info.[75]
Users can enable storage scopes instead of granting the storage permission to apps.[254] This will have the effect that the app can't see any of the files that were created by other apps, unless the user explicitly specifies files or directories that it should be allowed full access to.[268]
The GrapheneOS project is planning to add similar access scopes for other things such as Location, Camera, and Microphone.[76]
Although these are available in stock Android too, it might be noteworthy that there are toggles for disabling access to the microphone and camera. They are also available as quick tiles when swiping down the status top-bar.
While it might be tempting to disable access to these globally and only turn them on when needed, this might end up being very inconvenient when you quickly intend to snap a photo (eg. via the power button double-press shortcut) or when you want to accept a call while the phone is still locked. In these cases, you'd first have to unlock the phone and enable the appropriate access, which could take so long that the person calling decides to hang up. Instead, you could leave the system-wide access to microphone and camera enabled and deny these permissions at a per-app level: Leaving them enabled for the phone and camera app while setting all others to 'Ask every time'.[219]
If you're certain that you'll never need any of these sensors anyway, you could even buy one of Nitrokey (opens in a new tab)'s modified Pixel phones where the hardware components have been physically removed.[161]
GrapheneOS system-update download and installation is automatic and happens seamlessly in the background.[265] A reboot is still needed for them to take effect[73], but this process comes without risk thanks to the automatic rollback if the first boot of the updated operating system fails.[265]
Automatic reboots after an update are possible but disabled by default as these could happen in the middle of a phone call.[239] If you want to avoid updates being downloaded using cellular data, you should change the 'Permitted networks' setting to 'Unmetered' only.[231] Some users have reported that updates heavily drain the battery and cause the device to heat up, which can especially get in the way while you're not home. You can turn on the 'Require device to be charging' toggle to avoid such cases.[227]
It's possible to completely disable automatic updates by disabling the 'System Updater' app.[271] The GrapheneOS project strongly recommends against this, as you won't be getting privacy and security patches fixing vulnerabilities or adding improvements.[203]
Some may be concerned whether a future update could introduce a backdoor. There are several measures in place to prevent malicious updates: They must have a valid cryptographic signature, which is enforced by both the update client as well as the verified boot mechanism. Things like downgrade attacks are also prevented locally.[16]
The GrapheneOS project further argues that existing legislation can only target individual users, and cannot coerce malicious updates to be deployed to all GrapheneOS devices.[9] Because the updater doesn't provide any uniquely identifiable device information while requesting system updates, GrapheneOS won't be able to comply with a government's demand to send a backdoored update to a specific user. The update server will however be able to see the requester's IP address, which can be obfuscated by using a VPN or Tor.[270]
GrapheneOS comes with Seedvault (opens in a new tab) integrated at Settings » System » Backup as a solution for creating backups or moving from one device to another. Bear in mind that if you're using secondary user profiles, you'll need to set it up in each profile separately.[240] Some apps like Signal or Molly use a type of encryption of their application's database that can only be backed up and restored through these apps themselves.[46] If you're planning to use a USB drive to store your backups, a common best practice is initially creating the backup in the device's internal storage, and only moving it over to the drive once it has finished.[240]
There's also a known issue where backing up user files from storage might not include all of your files, therefore you shouldn't rely on Seedvault to include all of your important files yet. You may want to backup your important files separately, eg. to your laptop using a USB connection (Use USB for 'File Transfer'). But here too you'll have to establish the connection for each profile separately. GrapheneOS is hoping to replace Seedvault with a better and more reliable solution in the future, although there are currently tasks that have higher priority.[205]
User profiles mimic having separate phones to allow multiple users to share the same device.[192] In the following, we'll be exploring how this can be used to isolate apps from each other and compartmentalize the user's data. Though before that, I'd like to point out that the isolation that the app sandbox provides and the compartmentalization offered by access scopes will already be sufficient for many users.
On a freshly installed GrapheneOS, multiple users are disabled by default. Even so, when you unlock your phone after booting, you'll log into the "Owner" user, as in "The user who is the owner of the device". The Owner user shouldn't be mistaken for something like a privileged "root" user from Linux. Although the Owner has more administrative control over the device than other users, regular apps have the same access when running in Owner as they would in any other user profile.[192]
Each user is encrypted with their own keys protected by their respective lock method.[261] The Owner user is special in the sense that it does not only store the Owner's data, but also sensitive system-wide operating system data. Because of this, you always need to unlock the Owner profile first before any other user profile can be used. The Owner profile, and the apps running within it, will always be running in the background while you're using another profile. Nonetheless, the Owner profile does not have any access to the data stored in other profiles.[281]
As visible in the screenshot above, it's noteworthy that you can actually receive notifications from another profile that is running in the background. Although the notification will only tell you in what profile it happened and by what app it was triggered, this is still an addition by GrapheneOS that significantly improves the user experience with secondary user profiles.[7][25]
Before continuing on the different types of user profiles available, we should first discuss what even the advantages of using multiple profiles, compared to only using the Owner profile, are.
First of all, after setting up a new user you'll be greeted by a phone that appears to be in the state of being started for the first time. None of the user-apps you've already installed are there, everything is empty.[261] This can be very useful if you want to log into different users of the same application, eg. if you want to use a messenger with multiple accounts, but the app does not support that, you can simply install it twice in different profiles.[233]
Separating apps between different profiles will also prevent them from easily being able to communicate with each other. For example, there's the normal Facebook platform app but also the separate Facebook Messenger app. If both apps agree to it, they can use something akin to inter-process communication to exchange information between each other - but only if both of them are running within the same user profile.[25][261]
As mentioned, if you have apps that run in the background of your Owner profile, they will always be running unless you manually stop them from doing so. If you have applications that you rarely make use of, it makes sense to install them in a secondary user profile. Once you're done with them you can hold the device's power button and you'll be offered to end that user's session. This will make sure that all apps of that profile are stopped and their data is put to rest and fully encrypted.[281]
You can also create and use user profiles only temporarily and immediately delete them afterward. As apps installed within one user are not aware of the other users, you can use profiles like a browser's incognito mode. A profile's filesystem is completely isolated from other profiles, and although you could set up a storage scope to achieve the same, there'll be no need to do that since your temporary profile will be empty.[282]
Further above, we've talked about how the Auto-Reboot feature was added to ensure that data is eventually put to rest and no unencrypted data will be available for forensic companies to extract. If you employ a secondary user profile instead of the Owner for your regular usage, this will be much less of a problem: While putting the Owner's data at rest requires a reboot, putting a secondary user's data at rest simply requires ending their session.[281]
GrapheneOS raises the limit on the number of secondary user profiles from the standard 4 to 32, where one of them is always reserved for the guest user.[114][261] However, being able to create so many user profiles does not mean that all of them can run concurrently as that would impact the device's performance rather negatively. GrapheneOS scales the number of maximum concurrent users based on the amount of RAM built into the device.
If you have user profiles for use cases where it's never necessary for that user to keep running in the background, you can un-toggle 'Allow running in background' when editing that user via the Owner profile. That way you don't have to explicitly end the user's session, because simply switching away from that user will put the profile to rest.
You might be surprised to find out that it's possible for user profiles to update each other's apps, and also for the Owner user to be able to install his app into another profile. Didn't we say that the file systems of each profile are completely isolated? Well, yes - but it's not like each profile is running on a completely independent operating system, and it turns out that the code of applications isn't actually stored within each user but in the underlying system that is shared between all of them.[113]
The fact that the Owner is able to install apps in other profiles as long as they're already installed on the Owner means that we don't actually need to install app stores in every profile to get the apps we need. Instead, we could use the Owner profile as an "App Command Center"[232]: We install app stores solely in the Owner user. When we install new apps we uncheck giving them the Network permission and immediately mark them as disabled.[263] Then we open the user management and install the newly installed apps into the profile where we'll actually use them.
There are some inconveniences that come from making active use of secondary user profiles. For example, the Auto-Reboot feature will cause all user sessions to end and throws you back to unlocking the Owner profile first. That also means that all apps in those profiles will be forced to stop running and you'll miss out on receiving notifications from them until you log back into that user. Assuming you didn't set a very short time for Auto-Reboots, this shouldn't happen too often though.[224]
As mentioned, the file systems of profiles are completely isolated, which means there's no native way to eg. share a meme that you saw on social media in one profile via a messenger that is running in another profile. Typical workarounds include having cloud-based file synchronization (opens in a new tab) or a messenger installed within both profiles - but that will require an Internet connection and potentially wastes your mobile data. You could set up local file synchronization using apps like Syncthing (opens in a new tab) or an FTP server+client app - but these are usually annoying to set up. If you're already on Linux with a KDE desktop you might as well use KDE Connect (opens in a new tab) to exchange files between all of your devices and profiles. If not, the Inter Profile Sharing (opens in a new tab) app I've built out of frustration on this issue will hopefully be your best friend. If you really want to avoid installing any apps for this, your best option is getting a USB Stick with a USB-to-USB-C adapter.[302]
If you're installing apps in secondary profiles that require SMS verification, you might need to temporarily enable 'Turn on phone calls & SMS' for that user.[225]
The private space feature is a recent addition to Android.[67] Technically this is simply a secondary user profile that is nested within the Owner profile: When the space is locked, the private profile user is stopped, and when the space is unlocked, the user profile is started. Except for the shared clipboard with Owner, it's separated the same way as a secondary user profile.[109][293]
The advantage of using a private space over a secondary user profile is that the UI, in places such as notifications and settings, will be "merged" while the space is unlocked. That means if there's a notification from within the private space, it will be fully displayed in the Owner profile (compared to normal secondary users where this will only show the user and app name). While this makes it slightly less isolated than a dedicated user, private spaces can be a lot more convenient.[7][111][112]
Compared to having up to 31 secondary user profiles, a device can only have a single private space and it must always be part of the Owner.[114][124][293] The GrapheneOS project is considering changing this though, among other improvements for private spaces.[67][120] It's also noteworthy that the private space user is not listed within the user management interface, meaning features such as installing Owner apps into the private space are not available. Furthermore, locking the private space does not purge the encryption keys as well as ending a secondary user's session would.[6]
A drawback of private spaces, compared to full secondary user profiles, is that it's not possible to grant it access to 'phone calls & SMS'. This prevents verification via SMS from working and prohibits using some apps within private spaces.[13][110]
Work profiles are similar to private spaces in terms of user experience. They were originally designed for BYOD (Bring Your Own Device) deployments for corporations, which is why you need a separate "device manager app" to create them.[233] This app, and through it the corporation it belongs to, has control and ownership over the data within the work profile. However there are local management apps, such as Shelter (opens in a new tab)[124], that allow the creation and management of a work profile without an external owner.[120] Either way, you'll always have to place trust in a third-party app to use work profiles, unless you program your own.[233]
GrapheneOS calls work profiles created by apps like Shelter a "poor man's private space"[120], and strongly recommends using real private spaces instead.[109] Like private spaces, you can only have one and it must be located in the Owner profile. It's absolutely possible to use both a work profile and a private space alongside each other though.[102][114]
Private spaces have better isolation, proper encryption, and better user interface integration with the Owner profile.[109][120] Work profile management apps can enable a lot of communication between the Owner user and the nested work profile.[113] For example, work profiles do not block the communication of applications between profiles, which may increase convenience but negatively impacts privacy and security.[233]
For using VPNs the general best practice is that each of your devices should have a separate VPN connection that will obtain a separate exit IP address. [247] Because of this, all profiles (including work profiles and private spaces) have their own VPN configuration by design. This prevents an external party from tying them together based on the same exit IP address.[237]
You can prevent a profile from ever directly accessing an Internet connection by enabling the 'Always-on VPN' and 'Block connections without VPN' toggles by default.[266] GrapheneOS has made many improvements to Android to prevent connections from leaking, ie. bypassing a VPN connection. Although there are still some known cases of VPN leaks, fixing these is one of the top priorities of the GrapheneOS project.[264] These toggles can even be exploited to create a secondary user profile that has no Internet access at all, if you have a use case for that.[242]
At the moment, the GrapheneOS project only recommends using the official WireGuard app and the official Mullvad app. Mullvad is generally preferable though, as it works well with Graphene's exploit protection features turned on.[246][286] To avoid fingerprinting and tracking, GrapheneOS recommends using the default, network-provided DNS servers to blend in with other users.[285]
Remember that while each profile has its own VPN configuration, the underlying networking is shared. Because of that, it's currently possible for apps with the Network permission to communicate across profiles via localhost, which is what I'm using for the Inter Profile Sharing app to function. But this will likely change in the future as the GrapheneOS project is planning to introduce separate network namespaces for each profile.[193]
A fresh install of GrapheneOS comes with a very minimal amount of apps, and there are several reasons for that: Bundling additional apps with the operating system will increase the attack surface right from the beginning, GrapheneOS prefers users to be able to choose which apps they want to install based on their own judgment. GrapheneOS is focused on meaningful improvements to privacy and security, bundling more apps into the operating system would likely not only be outside that focus but even counter to it. GrapheneOS also wants to avoid bundling apps and services of third parties as few of those would actually be aligned with its goals and values.[157][174][290]
You may notice that among these few apps, GrapheneOS actually comes with its own 'App Store'. Note that this app repository is mostly intended for the distribution of Graphene's own first-party applications, and hardened versions of externally developed open-source apps. The list of available applications will be purposefully kept minimal, while third-party apps should seek to be included in Accrescent - the officially endorsed app store of GrapheneOS, which can be installed via Graphene's minimal store.[84][143][262]
Of the few apps that GrapheneOS comes with, about half of them are inherited from the Android Open Source Project with minor changes and are very primitive in terms of functionality and user experience. Many of the AOSP apps were great choices 10+ years ago when Android's UI was more primitive and expectations were far lower. Over time Google replaced them with more modern versions for their stock OS but abandoned the open-source versions.[185] GrapheneOS is planning to overhaul or replace them as well, though there are often licensing issues with possible alternatives.[174]
If you prefer Google's versions of apps such as the Camera, Gallery, and Keyboard, you can absolutely switch back to them without opting into their invasive usage statistic reporting and without uploading your photos to their service.[94] Some of Google's stock Android apps, such as the screenshot editor (Markup) and the Thermometer (for Pixels with the appropriate sensor), are mirrored in Graphene's App Store as they're not available in the Play Store.[85]
The Camera app that GrapheneOS comes with has already been modernized[174], it's focused on privacy and security and is arguably better than any of the open-source alternatives and even most paid apps. It includes modes for capturing images, videos, and QR/barcode scanning.[273] It has basic HDR+, Night mode, multi-camera zoom, EIS, etc. There's no loss in terms of photo quality of the camera by running GrapheneOS instead of stock Android.[131]
But still, it does not have the full set of features offered by the stock 'Pixel Camera' app. The Pixel Camera, previously Google Camera, can take full advantage of all available cameras and image processing hardware on GrapheneOS.[188][204]Though to reduce attack surface, direct access to low-level hardware by Google's Apps is controlled by an extra toggle.[273] The 'Special access to hardware accelerators for Google apps' toggle is enabled by default but does not grant these apps any additional access to data.[188]
GrapheneOS is planning to completely replace the current AOSP Gallery app, unfortunately, there's currently none available that has both acceptable licensing and proper image editing.[174] If you are looking for a good open-source alternative, Graphene as mentioned IacobIonut01/Gallery (opens in a new tab) and Aves (opens in a new tab).[185]
You can also install the 'Google Photos' app, that you'd get with stock Android, via the Google Play Store. It'll be able to make use of most of the AI features as well as hardware acceleration.[85][207][210][211]
Graphene's default keyboard is essentially Google's Gboard from 2014. It used to be an open-source project with a few closed-source components but ended up becoming entirely closed-source and rebranded to Gboard. It's missing some features such as sliding on the space bar to move the cursor, one-handed mode, better handling of emojis, and especially swipe typing.
Google's modern Gboard is definitely one of the nicest keyboards at the moment. Using it is fine as long as you don't opt-in to usage statistics and other invasive options. Remember that active keyboards have access to all the text you're entering, the text you're editing and the clipboard contents at all times.
If you're looking for an open-source alternative, you should have a look at FlorisBoard (opens in a new tab). Its user interface isn't very polished yet, but it's an improvement in terms of features compared to the default keyboard. The GrapehenOS project is considering forking and moving to it in the future.[94]
GrapheneOS includes their Vanadium subproject which is based on Chromium with enhancements in privacy and security. It's used by both the operating system as default browser as well as by other apps that need to render web contents. The GrapheneOS project recommends this browser to be used as is; additional browser extensions or modifications are only likely to make you stand out more, making you easier to track. To prevent websites from accessing standard sensors, you can toggle off the 'Sensors' permission for the browser app as a whole.[272]
There's currently only a tiny subset of Android apps incompatible with GrapheneOS. These are specifically apps that make use of the Play Integrity API which requires the operating system to be officially certified by Google. This mainly affects apps of banking/financial nature, location-based competitive games like Ingress, as well as some strange outliers such as the McDonalds app, Authy, and the Uber app for drivers. By implementing it, these apps have chosen to ban the use of alternative and modified operating systems. While this makes somewhat sense for games as basic anti-cheat system, it is by far not as effective as Google makes it out to be.[72] [130][133][136][156]
This also prevents NFC payments made via Google Pay. A simple way around this restriction is using a Pixel or Galaxy Smart Watch paired with GrapheneOS.[115] Fortunately, there are other services, such as those provided by European banks, that have their own tap-to-pay which works on GrapheneOS.[29][68] For the US there's hope that Curve Pay will be available soon.[115][130]
Although GrapheneOS provides the same standard security model as stock Android does, Google certifies operating systems not based on security but whether they licensed it.[79] There are ways to bypass some of these restrictions, but they would likely be blocked in time and would only be a temporary workaround.[70] According to the GrapheneOS project, the only permanent solution is regulatory or legal action based on this being highly anti-competitive and illegal behavior.[71][103][206]
Another caveat to Graphene's app compatibility is that some applications have a dependency on Google's Play Services, which is most often the case for messengers and social media. The reason for this is that they rely on receiving events for notifications through Google servers via Firebase Cloud Messaging (FCM). Some of these apps are able to fall back to their own implementation of push messages or frequent polling, but this typically requires the app to run with a foreground service. The app may also require being given 'Unrestricted' background usage, otherwise it'd be interrupted by the automatic battery optimization, causing delayed notifications.[238][288]
An example of this is Signal, which will fall back to its own push mechanism when FCM is not available. There have however been reports that this performs badly and inefficiently (draining the battery). Instead, the alternative Molly (opens in a new tab) client is often recommended for use without Play Services.[33]
For apps that have a hard dependency on Play Services, you have the option to install and use the official Google Play Services restricted to the standard app sandbox. Thanks to the compatibility layer Google Play will receive absolutely no special access or privileges on GrapheneOS. It provides nearly complete compatibility aside from a small subset of functionality that hasn't been ported yet or cannot be provided due to being inherently privileged. The Play Store and its services are fully available, including in-app purchases and app/content license checks. It can install, update, and uninstall apps as usual, assuming it has been given authorization as an app source and consent for each action.[250]
To make use of the compatibility layer, install 'Google Play services' from the GrapheneOS App Store. This will also install the Play Store, which is a dependency of Play services (don't disable the store app or the services will stop working too).[238] While making use of the Play Store requires being logged in with a Google Account, there's no need to log in if you're only installing Play Services for app compatibility reasons.[276] Also note that some apps including Signal need to be installed after sandboxed Google Play in order to make use of it properly.[104]
After installing Play Services you'll get a 'Missing optional permission' notification from the compatibility layer. Tapping it will ask whether you want to allow Google Play services to always run in the background, which will keep a connection open to Google's FCM server for reliable notifications, but will also reduce battery life. Agreeing to this will set the background usage to 'Unrestricted'. Leaving it on 'Optimized' will heavily restrict background usage based on how much it is used, while disallowing it will prevent background usage near totally. Make your choice depending on how important push notification timeliness via FCM is to you.[226]
In terms of security, it does not make much of a difference in which user profile you install Play Services. If you're hoping to avoid Google as much as possible, it's best to install it in a profile that you're not planning to use as your main profile.[276] For example, if you were planning to only use your device with a single profile, it would be best to install Play Services within the Owner profile's private space.[58][109]
I'd recommend installing Play Services in the Owner profile with background services disabled but authenticated with a Google account (it's possible to create one anonymously). The Owner profile will only serve to download and install apps (without Network permission, and apps immediately disabled after the download) which can then be installed into other profiles via the user management UI. This way you can have a secondary user profile within which Play Services are installed with 'Unrestricted' background usage, but without being authenticated to a specific Google account. Into this profile, you can install the messengers and social media apps that require FCM for reliable notifications.[232]
If you've connected your Android phone with your car before, you're probably familiar with Android Auto. Originally, it requires privileged access but Graphene's sandboxed Google Play compatibility layer makes it work with a reduced level of privileges.[151] You can install and use the official releases of Android Auto[278], but it must be installed through the GrapheneOS App store.[11][41] On the other hand, for apps like Waze (opens in a new tab) to be available through Android Auto they must be installed from the official Google Play Store.[37]
After installation, you have to open Settings » Apps » Sandboxed Google Play » Android Auto, and at least enable 'Allow permissions for wired Android Auto'. If you can't get it working with this toggle alone, you may need to grant it wireless permissions too. Additional permissions for rerouting audio, phone calls, and notifications to Android Auto can be granted at your own judgment.[278] Note that Android Auto currently does not function from within a private space or work profile.[118]
In Android, the package files downloaded to install or update an application are cryptographically signed. Once an app has been installed, the signer of the installation package is 'pinned' such that all future packages attempting to update it must have a signature of the same signer. This principle is called Trust-On-First-Use (TOFU) and it ensures that future updates of an application cannot come from malicious sources.[190]
But this still does not guarantee that the package that you used for the first installation of the application actually came from the source you thought it does. Here, app stores play a useful role in establishing who the real signer of an app should be, basically by pinning the signer through the app store's metadata before even downloading the application's package.[164] On the other hand, an app store adds another third party that you have to trust, and this is where Obtainium can be used as a mitigation.[14]
Obtainium (opens in a new tab) allows you to get Android apps, and keep them updated, straight from the source - ie. straight from their GitHub releases page.[22] By combining it with AppVerifier (opens in a new tab) you can still ensure that the package file you're about to install truly comes from the real developer of the application. This makes managing you apps more decentralized without sacrificing an important security feature that app stores offer. Though the GrapheneOS project argues that the most decentralized solution would be replacing Obtainium with self-updating apps.[162][163][190]
Accrescent (opens in a new tab) is an app store with a security-first mindset led by a contributor to the GrapheneOS project. It's available on the GrapheneOS App Store, although Accrescent is still in the early stages of development and so far only contains a small selection of applications. The GrapheneOS project intends to delegate securely hosting a wide array of third-party applications, both closed- and open-source, to Accrescent while the operating system's own app repository will only provide first-party applications and possibly a small number of lightly modified and hardened forks of useful third-party apps.[14][84][303]
While the hope is that Accrescent will be one of the best ways to obtain apps on GrapheneOS going forward, it still lacks funding and contributors to substantially expand. The GrapheneOS project is actively supporting this in a move to replace F-Droid, which they have called out many times for their problematic security stance.[22][143]
Accrescent appropriately secures the initial download and installation through its signed metadata without the need to use AppVerifier or to check the key fingerprint manually, although that's still possible to do after installation if desired.[190]
F-Droid (opens in a new tab) is well-known for being an exclusive repository for open-source Android applications. The GrapheneOS project has expressed very harsh criticism of F-Droid and does not recommend it as a secure source for third-party applications. The main reason is that F-Droid builds most of the apps directly from source on 'sketchy, outdated infrastructure', the resulting packages of which are then cryptographically signed by them, raising concern for a future mass-compromise of F-Droid users.[22]
An advantage of app packages being signed by the developer is that it requires the signing key to be compromised for the attacker to be able to create a malicious package with a valid signature. This is arguably harder to achieve than introducing malicious changes to the source code on platforms like GitHub which F-Droid would then use to blindly build a signed package from. The GrapheneOS project argues that this greatly increases the risk of supply chain attacks.[190]
Another problem stems from the fact that F-Droid self-signs app builds without ensuring that their build variant has a unique app id different from the one signed by the developers. Because the Trust-On-First-Use principle requires the signers of apps with the same id to match, this often causes confusion with users who try to reinstall an application within another profile or from a different source. Only the few applications that make use of F-Droid's reproducible build feature are excluded from this issue. For apps configured to use reproducible builds, F-Droid will discard their self-build package after verifying that it matches the developer-signed version. But at the moment it's not even possible to easily tell which apps are actually making use of this feature.[113]
While F-Droid made an attempt to secure first-time installations through metadata signing, their approach turned out to be rather flawed.[303] There are more issues the GrapheneOS project notes in discussions on F-Droid, though not all of them are technical and therefore omitted here.[158][164]
At the moment, the official Google Play Store app is still the most secure way to install closed-source apps, especially compared to using mirror sites like APKPure (opens in a new tab) which basically have copies of all application packages of the Play Store - commonly used to bypass regional restrictions.[276] To reiterate, Google's Play Store and Services apps are treated like regular apps with no special privileges on GrapheneOS, whether you want to separate them into a secondary user profile is up to you.[52][53]
The Aurora Store (opens in a new tab) is an alternative client to the Google Store's app repository. It allows you to avoid installing the official Play Store app and offers using an anonymous Google account that you share with other Aurora users. The GrapheneOS project recommends against using Aurora due to its security being weaker and some apps being affected by Aurora as the app's source. Note that you can always create a non-identifiable account with a burner phone number in the official Play Store instead of using Aurora's rather unreliable anonymous account feature.[19][21][22][26][28][77][139]
There's some criticism here on whether using so much of Google's applications, services and infrastructure doesn't defeat the purpose of using GrapheneOS. To this, the project clarifies that Graphene's purpose is not specifically avoiding Google, but providing a high level of privacy and security - even for those who do not want to make great sacrifices in terms of user experience. The ongoing work to provide a fully functional compatibility layer for Google's services is not a trivial feature but one that GrapheneOS is investing a lot of resources into. Either way, a fresh installation of GrapheneOS is completely de-Googled and whether you want to make use of the compatibility layer or avoid it, is completely up to you.[108][105][187]
Determining your location is another service originally provided as part of Google's Play Services. Instead, GrapheneOS by default re-routes location requests to the operating system[250][138], which exclusively uses the satellite location (GNSS) and therefore requires having satellite reception.[166] Due to this being unavailable or unreliable in situations where the sky is obscured, eg. by the concrete of a ceiling, there have been many complaints about location-based applications not working properly on GrapheneOS.[1][2][3][74]
If you have a cellular carrier and Internet connection, the device should be able to use assisted satellite geolocation (A-GNSS) by requesting information on nearby cell towers (SUPL) and on things like the current orbits and status of satellites (PSDS). These make acquiring a lock on your location significantly faster. By default, GrapheneOS uses the project's own proxy servers to prevent associating your SUPL/PSDS requests with your IP address.[4][175]
You can optionally turn on Wi-Fi and Bluetooth scanning under Settings » Location » Location services. This will allow apps and services with the 'Nearby devices' permission to scan for nearby Wi-Fi networks and Bluetooth devices even while Wi-Fi and Bluetooth are turned off, potentially improving location-based features.[229] This information would typically be sent to Google's servers by Play Services to determine the location more accurately even inside buildings. The GrapheneOS project is in the process of creating its own implementation of this, likely first as a proxy to Apple's servers and later as its own database.[5][61][81]
If you have sandboxed Play Services installed and want to use Google's network location service to provide improved location estimates, you first have to disable the 'Reroute location requests to the OS' toggle at Settings » Apps » Sandboxed Google Play. Next, you'll have to change the Location permission of Play services to be set to 'Allow all the time' as well as 'Use precise location'. For it to be able to make use of network scanning, you also need to grant it the 'Nearby devices' permission (the above-mentioned toggles for Wi-Fi and Bluetooth scanning must already be enabled). Finally, you need to once again go to Settings » Apps » Sandboxed Google Play and tap on 'Google Location Accuracy' and enable the 'Improve Location Accuracy' toggle.[2][60][82][175][276]
The re-routing toggle is not a global option, so you could consider setting up a secondary user profile for the sole purpose of making use of Google's privacy invasive location services for when you're having geo-location troubles.
We've already mentioned that it's not surprising for applications on GrapheneOS to crash or otherwise refuse to work properly, but this is nearly always fixable.[18] Before anything, you should first attempt standard steps such as clearing app cache, forcefully stopping and restarting the application, restarting the phone, or re-installing the application. Typical GrapheneOS-specific solutions include turning off some of the exploit protection measures, re-installing the application outside of a private space (Owner or other secondary profile), re-installing the app in a profile that provides sandboxed Google Play Services, etc.[8][12][39][208][218] Sometimes apps even start crashing because the application (eg. app store) from which they were installed from is no longer enabled or installed[241], or they refuse to work properly because they were not installed from the source that they expected.[19]
Typical reasons for this have also been explained above: You're attempting to install an application that is already available with a higher version or from a different source in another user profile.[36]