Graphene OS: a security-enhanced Android build
GrapheneOS got its start as "CopperheadOS"; it was reviewed here in 2016. A couple of years
later, though, an ugly dispute between the two founders of that project led
to its demise. One of those founders, Daniel Micay, continued the work and
formed what eventually became GrapheneOS, which is, according to this history page, an
independent, open-source project that "will never again be closely tied
to any particular sponsor or company
". Work on GrapheneOS is supported
by a Canada-based foundation created in 2023; there appears to be almost no
public information available regarding this organization, though.
At its core, GrapheneOS is an effort to harden Android against a number of threats and to make Android serve the privacy interests of its users. It is based on the Android Open Source Project, but removes a lot of code and adds a long list of changes. Some of those, such as a hardened malloc() library or the use of additional control-flow-integrity features, will be mostly invisible to users (unless they break apps, of course, which has evidently been known to happen). Others are more apparent, but it is clear that a lot of effort has gone into making the security improvements as unobtrusive as possible.
Installation
Some Android rebuilds prioritize supporting a wide range of devices, often with an eye toward keeping older devices working for as long as possible. GrapheneOS is not one of those projects. The list of supported hardware is limited to Google Pixel 6 through Pixel 9 devices, with some trailing-edge support for Pixel 4 and 5 devices. Even then, though, the newer devices are strongly recommended:
8th/9th generation Pixels provide a minimum guarantee of 7 years of support from launch instead of the previous 5 year minimum guarantee. 8th/9th generation Pixels also bring support for the incredibly powerful hardware memory tagging security feature as part of moving to new ARMv9 CPU cores. GrapheneOS uses hardware memory tagging by default to protect the base OS and known compatible user installed apps against exploitation, with the option to use it for all apps and opt-out on a case-by-case basis for the few incompatible with it.
My phone had been making it clear for a while that it could not be counted on in the future, but the prospect of buying a new one inspired a lot of trepidation. Each new device seems to come with more privacy-hostile "features" and intrusive AI "assistants"; finding all of the necessary "disable" switches is a tedious and error-prone task. That, along with the news that Google's "Gemini" feels increasingly entitled to a device-owner's data regardless of its configuration, inspired the purchase of a Pixel 9 device that would be used to experiment with GrapheneOS to see if it could replace stock Android for everyday use.
Flashing the firmware of an expensive device is always a bit of a nervous prospect; the GrapheneOS installer is designed to minimize the amount of fingernail biting involved in the process. There are two installation methods described in the documentation — a web-based install, and one that works from the command line. Naturally, I chose the command-line version. The instructions are straightforward enough: download the installation image, connect the device, and run the supplied script. Said script ran to completion and confidently declared victory at the end, but the device still only booted into normal Android — a repeatable result, but not quite the intended one.
Some investigation turned up the (undocumented) fact that the web installation method is seen as being rather more reliable than the command-line version. So I tried that, and it worked as intended; the GrapheneOS experiment had begun in earnest.
First impressions
Stock Android includes some nice features to make the move to a new device
as easy as possible — unsurprising, given the strong incentive to get
people to make that move often. Most of the data, apps, and configurations
that were on the old device will be automatically moved to the new one.
GrapheneOS has no such feature; a newly installed phone is a blank slate
that must be reconfigured from the beginning. One should expect to spend a
lot of time rediscovering all of those settings that were set just right some
years ago.
As can be seen from the screenshot to the right, the initial GrapheneOS screen is an austere and monochromatic experience. The system handles color just fine, but color is something for the owner to configure, it seems.
A stock Android install comes with a large set of apps out of the box, many of which the user likely never wanted in the first place, and many of which often cannot be deleted. GrapheneOS does not have all of that stuff. It comes with its own versions of the web browser, camera app, PDF viewer, and app store. Notably, GrapheneOS does not include the Google Play store or any apps from there (but keep reading for Google Play). The app store offers all of 13 apps in total.
The web browser is a Chromium fork called Vanadium. It enables
strict site isolation on mobile devices (which Chrome evidently does not)
and adds a number of code-hardening features. The documentation strongly
recommends avoiding Firefox, which is described as "more vulnerable to
exploitation
".
The camera app is said to be the best available in a writing style that is often encountered with GrapheneOS:
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, Pixel Camera can be used as an alternative with more features
The camera app strips Exif metadata by default, and location metadata must be enabled separately if it is wanted.
App stores
One other thing that can be installed from the GrapheneOS store is the Accrescent app store, which is an alternative repository that claims a focus on security and privacy. It provides access to a few dozen more apps, including Organic Maps, the Molly Signal fork, and IronFox, a hardened version of Firefox.
With those app stores, one can enable a certain amount of basic phone functionality, but the sad fact is that many of us will need a bit more than that. One alternative, of course, is F-Droid, which can certainly be installed and used on GrapheneOS. Hard-core security-oriented people, including those in the GrapheneOS community, tend to look down on F-Droid (see this article for an example), but it is a useful source for (mostly) free-software apps.
In the end, though, it will often come down to using the Google Play store; an Android device can be nearly useless for many people without the apps found there. GrapheneOS offers a sandboxed version of Google Play that turns it into an ordinary app without the special privileges that Google Play has on stock Android systems. It worked without a hitch here; the documentation says that some apps may not work properly, but I did not encounter any.
It is worth noting that Android provides an "integrity API" that can be used to query the status of the software running on the device. Among other things, it can attest to whether the secure-boot sequence was successfully executed, or whether the device is running an official Android build. GrapheneOS implements this API and, since it uses the secure-boot machinery, can pass the first test, but it is not an official image and cannot pass the second. Some apps care about the results of these queries and may refuse to work if they get an answer they don't like.
GrapheneOS will put up a notification for each use of this API, so it is easy to see which apps are using it. Most don't, but some definitely do. I saw a few apps query this API, but did not encounter any that refused to work; booting securely was good enough for them. Some others are pickier; there is a short list of apps that refuse to run under GrapheneOS available. Testing any important apps before committing to an alternative build like GrapheneOS is thus an important bit of diligence. One just has to hope that a future app update won't make a working app decide to stop cooperating; this is a definite risk factor associated with using any alternative Android build.
Security features
GrapheneOS includes a number of security and privacy features beyond the under-the-hood hardening. Many of them are designed to make the device work as if the owner of the device actually owns it. For example, the provisioning data included with Android, which tells the device how to work with carriers around the world, allows those carriers to specify that features like tethering are not to be made available. GrapheneOS never quite got around to implementing that part of the system. There is, instead, an option to prevent the phone from being downgraded to older, less-secure cellular protocols.
Standard Android gives control over some app permissions, but does not let users deny network access to an app. GrapheneOS does provide that control, though network access is enabled by default for compatibility reasons. If network access is disabled, the app in question sees a world where that access is still available, but, somehow, the device just never finds a signal. So apps should not refuse to run just because network access is unavailable (though they may, of course, fail to run correctly).
There is a "sensors" permission bit that controls access to any sensors that are not subject to one of the other permissions; these include the accelerometer, compass, thermometer, or any other such that may be present. This permission, too, is enabled by default but can be turned off by the owner.
The storage scopes feature can put apps into a sandbox where they believe they have full access to the device's shared storage, but they can only access the files they have created themselves. There is also a contact scopes feature that allows apps to believe they have full access to the owner's contacts, while keeping most or all of that data hidden from those apps.
GrapheneOS supports fingerprint unlocking, just like normal Android, with one difference: after five consecutive failures, the fingerprint feature is disabled for 30 minutes. An owner being forced to supply a finger to unlock a device can thus disable that functionality quickly by using an unrecognized finger. For those whose privacy needs are more stringent, a duress PIN can be configured; entering that PIN causes the device to immediately wipe all of its data. Needless to say, this self-destruct feature should be used with care.
There is a special app that can audit the state of a GrapheneOS device and, using the hardware security features, provide an attestation that the device has not been tampered with or downgraded to an older software version.
The project makes frequent releases, and installed GrapheneOS systems update aggressively. The project updated to the Android 16 release in early July, slightly less than one month after Google released that version. In the default configuration, the device will automatically reboot after 18 hours of inactivity as a way of pushing all data to (encrypted) rest; that also has the effect of making the device run the latest software version.
See also this page comparing a long list of security features across several Android-based builds.
Governance and community
One potential caveat is that the development community behind GrapheneOS is somewhat murky. As mentioned, a foundation exists to support this system, but there is little information about how the foundation operates beyond an impressively long list of ways to donate. The public registry information shows three directors: Micay, Khalykbek Yelshibekov, and Dmytro Mukhomor, but there is no public information on how directors are chosen or how the foundation uses its funds.
There is a vast set of repositories containing the project's source, but there is little information on how one might contribute or what the development community is up to. Some information can be found on the build-instructions page. The project runs a set of chat rooms and a forum, but they seem to be dominated by user-oriented conversation rather than development. Participation by the project in the forums comes from a generic "grapheneos" account.
In a response to a private query, the project claimed to have ten active, paid developers, most of whom are full time. One gets the feeling, though, that Micay is still the driving force behind GrapheneOS; if nothing else, the project's belligerent fediverse presence bears a lot of resemblance to his previous interaction patterns. What would happen if he were to depart the project is far from clear. There is a potential risk here that is hard to quantify.
Overall impressions
Setting up the device with GrapheneOS required a couple of days of work, much of which was dedicated to reproducing the apps and configuration on the older device. A certain amount of time must be put into setting the privacy features appropriately and giving apps the permissions they need to work. In the end, though, the device works just as well as its predecessor, with all the needed functionality present, and a lot of unneeded functionality absent. I have committed willingly to using it, and have no intention of going back.
The system is undoubtedly more secure, even if the invisible hardening changes do not actually do anything. The sandboxing is tighter, there is more control over what apps can do, and there is no AI jinni doing its best to escape its bottle.
The remaining problem, of course, is that, for many people, GrapheneOS alone will not be enough, and it will be necessary to let the nose of proprietary software into the tent. The documentation says that logging into the Play Store is not required, but it insisted on a login for me, re-establishing the umbilical connection to Google that installing GrapheneOS had cut. The keyboard does not support "swipe" typing; users who want that will likely end up installing GBoard, which poses privacy risks of its own. The GrapheneOS messaging app works, but Google's app can filter out some spam, one might as well toss it on. There are some reasonable, privacy-respecting weather apps on F-Droid these days, but the proprietary, privacy-trashing ones have better access to weather alerts (at least in countries that still have functioning weather agencies) and red-flag warnings. Android Auto is highly useful, and it works fine in GrapheneOS, but it requires its own level of special access permissions.
Then there is the whole slew of banking apps, ride-share apps, airline apps, and so on that, seemingly, are indispensable in modern life. Each of these pokes another hole into the private space that GrapheneOS has so carefully created. It is possible to live and thrive without these tools, and many of us know people who do, but the tools exist and are popular for a reason. For many, it is simply not possible to get by without using proprietary software, much of which is known to be watching our every move and acting in hostile ways.
Putting GrapheneOS onto a phone, at least, forces an awareness of each hole
that is being poked, and provides an incentive to minimize those holes as
much as possible. When potentially malicious software has to be allowed
onto a device that contains many of our closest secrets, the system will at
least do its best to keep that software within its specified boundaries and
unable to do anything that it is not specifically allowed to do.
Installing GrapheneOS orients a device more toward the interests of its
owner; that, alone, is worth the price of admission.
Posted Jul 24, 2025 13:51 UTC (Thu)
by DemiMarie (subscriber, #164188)
[Link]
Posted Jul 24, 2025 16:12 UTC (Thu)
by rjones (subscriber, #159862)
[Link] (2 responses)
For most applications I use most of the time Google umbilical cord is unnecessary. So all of those applications sit in my "owner" profile with no google services support. The majority are installed through the Obtainium app, which allows to manage and update applications directly pulled off the internet; typically apks generated as part of Github releases.
But in addition to "Owner" I have "Work" and "Play" user profiles. Both of which use Android apps pulled from Google Play store.
For example I bought a Bose noise cancelling headphones and while the Android app is not necessary for important functionality it does allow to manage bluetooth devices that the headphones are aware of and set custom noise cancelling profiles. So that ends up in the "Play" profile. I switch to the profile to configure the headphones and when I am done I shut it down and none of the stuff there remains active.
That way I have a degree of control over when these sorts of google related services are active.
Overall I am pretty happy with the switch to Graphene. The OS updates are frequent, but it is trivial to manage. It sends a message announcing a new update was downloaded and I need to reboot the phone to finalize the install. And that is it, no drama or brokenness. Pretty solid product in my experience.
Posted Jul 25, 2025 11:30 UTC (Fri)
by jcul (subscriber, #171954)
[Link]
Or having additional google profiles, I manage my wife's grandparents' google devices like this.
To be fair stock android allows multiple profiles, but of course not with the option of them being AOSP or Google play.
The private space on android is great too, I think it's an android thing and not just graphene specific.
Same thing for self managed work profile, which can be set up with shelter.
Though I actually do use shelter as a true work profile, so I can switch off slack, work email etc when not working.
Posted Sep 3, 2025 14:32 UTC (Wed)
by lemming54 (guest, #179149)
[Link]
> The storage scopes feature can put apps into a sandbox where they believe they have full access to the device's shared storage, but they can only access the files they have created themselves.
This is not correct, "scopes" make apps that are not requesting normal permissions compatible, by poking a hole in their sandbox that the user controls. Scopes are a compatibility tool for filesystem access, as many apps just request "all media" "all music" or even "all files" even though they only need a few folders (galleries, syncthing-fork, random apps). Contact scopes allows granular access to contacts, where there is no Android-native alternative like there is with the filesystem access portal.
All apps can access files they created themselves, in Downloads, Pictures, Music, Movies, Documents. That way for example you can add pictures on Signal where you cant use the "share" portal, share to the app then save with the app, now the app can access that file.
> installed GrapheneOS systems update aggressively
not really, can be configured like "only on charge"
> The documentation says that logging into the Play Store is not required, but it insisted on a login for me, re-establishing the umbilical connection to Google that installing GrapheneOS had cut.
You can use work profile, "Private space" and user profiles (which grapheneOs works hard to make more usable) to separate that out.
> The keyboard does not support "swipe" typing; users who want that will likely end up installing GBoard, which poses privacy risks of its own.
The preinstalled Keyboard is really bad and outdated. This was the version that Google made before making it proprietary as "GBoard". All the apps were abandoned in different Android versions, which is pretty obvious when looking at it (like the SMS or Gallery app having different UI styles)
Keyboard apps as user apps can input stuff and read the clipboard, thats it. You can (and should) deny keyboard permission. All apps can communicate on a voluntary basis via IPC even across the sandboxes, so if you have GBoard and another youtube app on the same user profile, one having internet access, stuff might go to Google. Otherwise, GBoard works fine.
But Keyboards like FUTO Keyboard, Heliboard and Florisboard exist, so this is not true.
> The GrapheneOS messaging app works, but Google's app can filter out some spam, one might as well toss it on.
As the spamfiltering will require internet permission, bundling the "Google Messages" app with "Gboard" means 2 potential partners communicating via IPC will be installed, one having internet access, the other knowing everything you type.
The writer will not have thought about this, so these easy comments can be quite dangerous.
There are alternative databases and methods to detect spam callers, like the now discontinued "Carrion" from DivestOS or ACRPhone's service.
> There are some reasonable, privacy-respecting weather apps on F-Droid these days, but the proprietary, privacy-trashing ones have better access to weather alerts (at least in countries that still have functioning weather agencies) and red-flag warnings.
Very vague statement. There are tons of providers, many of which are supported by apps like Breezy Weather.
The DWD in germany was forbidden to give out their app for free in a courtcase against weather.com, which is a shame. But "kleine wettervorschau" uses the exact same data, for free and being free software.
The Project "FOSS Warn" which now has bundled with KDE, allows to get official emergency alerts for germany and in the future a lot more countries.
> Android Auto is highly useful, and it works fine in GrapheneOS, but it requires its own level of special access permissions.
True, but (while I wouldnt trust it with my data, let alone trust a car), GrapheneOS allows to at least sandbox the app from a lot of confidential information.
> [...] banking apps, ride-share apps, airline apps, and so on that, seemingly, are indispensable in modern life. Each of these pokes another hole [...]
They can be isolated in user profiles, work profile, private space. They can be behind Orbot/TorVPN, a different VPN, or a different way to isolate them. They have no access to much private information. As these apps are a requirement, GrapheneOS has worked a lot on improving existing sandboxing systems to make them less invasive.
GrapheneOS is very barebones, as they focus on OS improvements instead of fancy apps (they are developing apps though, and look for developers who know Android app development). Assume that you will disable many preinstalled apps and replace them with better ones.
If you are looking for app recommendations, here is a list: https://alternativeto.net/lists/41859/grapheneos-starterpack
Posted Jul 24, 2025 22:04 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (3 responses)
https://grapheneos.org/usage#sandboxed-google-play-instal...
Posted Jul 24, 2025 22:18 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Jul 25, 2025 0:09 UTC (Fri)
by rjones (subscriber, #159862)
[Link]
Aurora depends on logging into Google to get access to the playstore stuff, but using your personal account is optional. It'll use a generic aurora account or something like that by default.
It has been a while since I did my Graphene OS install so I don't remember for certain, but I don't think it prompted me for google login on first boot. I didn't give it to it if it did. It isn't required by the OS by default.
Posted Jul 25, 2025 11:14 UTC (Fri)
by vimja (subscriber, #91577)
[Link]
You can get proprietary apps through Aurora which will use it's own generic login.
Just if you have something that really-really needs Play services or if you want to buy apps or download a previously bought app, you'll need a Google account.
Posted Jul 24, 2025 22:16 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (4 responses)
https://grapheneos.social/@GrapheneOS/114784469162979608
Posted Jul 25, 2025 4:38 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Jul 25, 2025 5:02 UTC (Fri)
by donald.buczek (subscriber, #112892)
[Link]
That would at least be an indication of its effectiveness if criminal organizations, for whom privacy must be particularly important, were to rely on the system.
Posted Jul 25, 2025 6:23 UTC (Fri)
by danieldk (subscriber, #27876)
[Link]
> As it sounds . The phrase "every time we see a Pixel we think it could be a drug dealer" is as forceful as it is surprising. It comes from a Catalan anti-drug official for the Mossos d'Esquadra (Catalan police) who spoke to DiariAra about the phones they see during their operations. Far from being a Google problem (of course), the reason its phones have become popular among criminal gangs is, paradoxically, one of its greatest virtues for Android enthusiasts: its freedom. A freedom that, combined with the installation of an alternative operating system, makes it an almost infallible communication tool.
blown up by some Android news sites to a smear campaign for clicks.
Original source: https://www.xatakandroid.com/sociedad/cada-vez-que-vemos-...
Posted Jul 25, 2025 6:26 UTC (Fri)
by lunaryorn (subscriber, #111088)
[Link]
"Law enforcement in Europe"? Hardly so. More like "the regional police in one specific Spanish autonomous region which represents just about 2% of the whole EU population", according to one (machine translated) article in a Spanish internet outlet".
Neither the most reliable source nor national news. More like someone was desparately locking for some clickbait... and hugely blown out of proportion.
Posted Jul 24, 2025 22:39 UTC (Thu)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Jul 25, 2025 4:37 UTC (Fri)
by achak (subscriber, #178511)
[Link]
Posted Jul 26, 2025 13:06 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (2 responses)
They probably probably could be, if they were used that way.
Like how DVD region coding was labelled anti-competitive in Australia because its primary effect was to make the majority of DVD content unavailable to Australians.
So, if it turned out that a lot of popular apps started using attestation for inappropriate reasons, you might get some regulatory attention. But the current state I don't think there's likely to be a problem.
Posted Jul 28, 2025 13:17 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (1 responses)
https://github.com/eu-digital-identity-wallet/av-app-andr...
Similarly the govt id apps of many countries have the same issue:
https://grapheneos.org/articles/attestation-compatibility...
Posted Jul 29, 2025 12:36 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
Governments create markets. Distorting markets is their job. They destroy the market for assassination while creating the markets for digital goods.
The discussion about such apps requiring Google Android is an important one, but seems to be missing the point. Complaining "the EU is forcing us to use Google" is not a useful action. People need to be proposing viable alternatives. Perhaps working out what it would take for Google to sign Graphene OS. Or perhaps providing an alternate attestation API that would allow a national government to attest the security instead of Google.
People need to work the problem, not complain about the solution. The issue here is: how can someone prove they are over 18 without requiring them to submit their entire government ID with all their personal information. Continuing the current practice of sending copies of your passport/ID card/drivers license everywhere is viable, but (I hope you agree) not optimal.
Posted Jul 25, 2025 5:06 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
I just spent 5-10 min looking at some fights between /e/OS and GrapheneOS it was really painful to see. Supposedly, nothing unites like a "common enemy" but no: those guys manage to prove that wrong! I have no issue with "my security is bigger than yours" contests and other comparisons as long as the tone reflects a sane coopetition. But the tone I saw was not friendly at all. I don't have the time to fact-check or even read the technical assertions or verify "who started it" but it does not matter because the situation is very sad in any case.
The most mature side (again: I don't know which side it is) should just completely stop engaging on social media with the less mature side until the latter learns the most basic life skills (with most adults: never. Too late.) The former should still deal with any valid bug reported by the latter but they should pretend the report came from somewhere else and never engage directly.
Never. Feed. The. Troll. Always, always ignore it.
Posted Jul 25, 2025 6:24 UTC (Fri)
by acer (subscriber, #156526)
[Link] (2 responses)
Posted Jul 25, 2025 6:32 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Jul 25, 2025 13:28 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Jul 25, 2025 7:13 UTC (Fri)
by wsy (subscriber, #121706)
[Link] (3 responses)
Posted Jul 25, 2025 10:15 UTC (Fri)
by numgmt (subscriber, #167446)
[Link] (2 responses)
Notably, without Verified Boot, malware persisting at the lowest levels of the device is possible. It prevents rootkit persistence. Without verified boot, you have no guarantees. This is a compelling reason to have a locked bootloader with verified boot enabled.
In fact, it's a big reason why the Pixel is the only device GrapheneOS supports. Few other OEMs produce phones that allow you to re-lock the bootloader.
That being said, if GrapheneOS didn't exist, I'd be running rootful LineageOS or whatever the heck would get me a halfway decent experience instead of stock.
Posted Jul 25, 2025 16:09 UTC (Fri)
by wsy (subscriber, #121706)
[Link]
Posted Jul 31, 2025 17:29 UTC (Thu)
by raxod502 (subscriber, #172505)
[Link]
Yes, of course my having root access to my device makes certain types of attacks possible that were previously impossible, but on the other hand it also makes certain other types of attacks impossible that were previously possible. Everyone has a different threat model and the inability to recognize this seems both patronizing and unproductive to me. "Only a Sith deals in absolutes", right?
And if having root access to your device compromises it so severely that it's not even worth discussing, should we all throw our laptops and desktops in the dumpster? Is Linux cancelled because it doesn't have System Integrity Protection like macOS...?
Posted Jul 25, 2025 8:28 UTC (Fri)
by vimja (subscriber, #91577)
[Link]
So not too long ago, I switched to a Google Pixel 9a and installed Graphene. I've been very happy with it ever since. I don't use the Google Play services, not even microG.
I still need some proprietary apps, but I get those through the Aurora Store. That way I don't have to login to a Google Account. Without Google Play, some apps have missing functionality, most notable the push notifications which are not working. Also some Apps won't show a map where they should.
But with a single exceptions, all the apps I use work. Even banking and credit card apps (of 3 different banks), local public transport app for purchasing tickets on the phone, a local pay-by-phone provider (Twint), and a government provided authentication app all run.
Funnily enough, Twint is popping up warnings about the app not working without Play servcies. On every interaction. Twice. But after clicking those away, the app works just fine.
Day to day I mostly use Open Source apps and those run very well indeed. Many can use UnifiedPush for push notifications or come, like Threema Libre, with their own push implementation.
At the moment, I'm living a Google free and happy life ;)
Posted Jul 25, 2025 14:32 UTC (Fri)
by matchboxbananasynergy (subscriber, #178520)
[Link]
One is about the history of the project. The open source project has been the same from the beginning. It started as a solo project, was known as CopperheadOS for a time, then later was renamed to GrapheneOS. What is now CopperheadOS is a fork. See the following links:
-https://github.com/GrapheneOS/platform_manifest/forks?inc...
The above links show forks of our repositories dating back to 2016, which shows that GrapheneOS is the original project, not some spin-off that started later. The third link points to our legacy bugtracker, prior to the rename.
Regarding the failed cli install, we're not sure what happened there. Flashing that way works fine. We are aware that some issues can arise in certain cases, like when using OS-provided Fastboot. If you were to try again, we'd suggest making sure you are using the Fastboot mentioned in our install instructions to avoid these sorts of issues.
We usually suggest people flash GrapheneOS using the web installer because it's easier for most people. Also, as you found, the cli install is robust but uses more OS-provided functionality so more issues can occur due to bugs in the OS outside of our control especially if using an OS package for fastboot. We're glad you were able to install GrapheneOS easily with the web installer, though.
Regarding Play Integrity, it should be noted that there's nothing we can do if apps check for device or strong integrity since Play Integrity responses are signed by Google. The issue isn't one of whether we've implemented something or not. We do have a guide on how apps can add support for GrapheneOS using hardware attestation https://grapheneos.org/articles/attestation-compatibility..., which some apps have done, including Yuh and Swissquote.
Regarding the network permission, users can install apps without the network permission granted by unchecking the network permission box when installing the app.
And for the sensors permission, there is a toggle in Settings where apps can have the sensors permission not granted by default.
In the section about fingerprint unlocks and PINs are mentioned, it is worth explaining that the duress feature doesn't brick the device, it wipes keys from the keystore (among other things). After duress is triggered, the device will say it's corrupt, and from there it can be factory reset via Recovery.
It is mentioned that after 5 unsuccessful fingerprint attempts, you're locked out for 30 minutes. On GrapheneOS, it is permanent until you input your primary unlock method again. On the stock OS, it locks you out after 5 attempts for a time period and has permanent lockout until you input your primary unlock method again after 20 attempts.
A related feature is our 2nd factor fingerprint unlock feature. When using this feature, users can set a very strong alphanumeric password for the primary unlock method and use their enrolled fingerprint + a PIN for added security.
The best way to see what the project is prioritizing is by checking the issue tracker. Planned features have priority labels.
Development guidelines can be found in the build page that is linked there, under this section: https://grapheneos.org/build#development-guidelines, and if someone wanted to help contribute, they can express interest in our development room, or they can comment on an issue they are interested in contributing to.
The project has and is subject to attacks over the years, so most contributors prefer to keep their heads down and maintain anonymity. This way they are less likely to be targeted. We really care about protecting our project members, so we're taking the appropriate measures to do that.
This may be why from the outside it looks like Daniel Micay is still the driving force of the project, which makes sense because he's the founder and has always been the public face for the project. Nowadays, other developers do the majority of development work, including reviews. Nonetheless, his expertise remains invaluable to the project.
Some other thoughts:
- On the stock OS, Android Auto is a privileged app. On GrapheneOS it's sandboxed and only necessary permissions are granted if users toggle them on. Still more access than other apps, but configurable and better than on other OSes.
Posted Jul 25, 2025 15:07 UTC (Fri)
by michaelo (subscriber, #23907)
[Link]
Posted Jul 25, 2025 18:08 UTC (Fri)
by corbet (editor, #1)
[Link] (5 responses)
Posted Jul 25, 2025 19:20 UTC (Fri)
by DemiMarie (subscriber, #164188)
[Link]
Posted Jul 25, 2025 19:27 UTC (Fri)
by excors (subscriber, #95769)
[Link] (2 responses)
(I wouldn't bring that up if they indicated they had changed their mind about the accusation, but I get the impression they just realised they shouldn't have said it out loud because it makes them sound much less reasonable to other readers. The original response certainly backs up the article's comment on the project having a "belligerent fediverse presence".)
Posted Jul 25, 2025 20:02 UTC (Fri)
by corbet (editor, #1)
[Link] (1 responses)
Posted Jul 27, 2025 0:56 UTC (Sun)
by marekm (subscriber, #174682)
[Link]
Posted Jul 25, 2025 20:30 UTC (Fri)
by tschoerbi (subscriber, #88015)
[Link]
I hoped for the project to become more open over time and for a community forming around. Sadly, this doesn't appear to have happened. For the time being, I'll stay away from it simply as result who is running it. I'd rather not been seen as supporting this kind of behavior, or worse, being associated with it.
Posted Jul 26, 2025 23:15 UTC (Sat)
by cyphar (subscriber, #110703)
[Link] (1 responses)
Having seen examples of very mild constructive criticism added to the list of "attacks against the project" which are then used as justification for their uncooperative behaviour shows that this is an unfortunate pattern of behaviour. Obviously actual attacks against projects and individuals are unacceptable, but bog-standard criticisms being reframed without context as attacks is also not acceptable behaviour. There's a non-zero chance they will consider this comment to be an attack against them. I find it strange (but unsurprising) that they found this very positive and supportive LWN article to be somehow a mischaracterisation of their project that required responses rivaling the length of the original article (parts of which they appear to have now deleted according to the editor).
For the record, I did really find a lot of the technical work in GrapheneOS very impressive (I miss plenty of the privacy features now that I'm back to "stock" Google-Android), and I was quite happy to work through all of the necessary technical hurdles (apps not working, manually tweaking things to work with problematic apps, etc) to keep using it. Unfortunately, technical work is only one facet of the work necessary to create a thriving community. They would really benefit from hiring a PR person (preferably 10 years ago, but today is good too) -- even if only to have a third party proof-read their public statements.
Posted Jul 31, 2025 2:22 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Or - even better - such a public person could explain internally why some of these statements should never be written in the first place. Unfortunately, telling someone who pays you what not to do is very hard. Even harder than what to do.
If a project is successful, then it will statistically draw a lot of not-very-smart questions and debates. And that's OK; good leaders let users help each other. They manage their super precious time and provide such answers and corrections only when no one else could. Cause technical experts should focus on expert things, that's how the project is the most productive.
But maybe those contentious public statements are at least from people who stopped contributing technically? Can't tell since developers prefer to stay anonymous to protect themselves from "attacks"... of what nature? Threats or harsh code reviews? We have no idea either.
Also... editing or even deleting stuff published on the internet, really? That does not look serious. Fixing typos, sure; but that's not it.
Sharing a SubscriberLink in public, interesting...
That looks like a lot of weirdness and opacity for a project "opening" Android. Much more than just "developer privacy".
Posted Jul 29, 2025 0:46 UTC (Tue)
by dallardi (subscriber, #6247)
[Link]
I applaud the GrapheneOS team for their frequent releases and ease of updates which download and install in the background and I simply reboot into the new version at my convenience. I've never had an issue. The OS has been rock solid and super reliable.
I have a root/owner profile as well as a "Me" and a "GoogleMe" profile, which allows me to mimic what I do on my regular devices - namely, my normal user profile is a non-privileged user and is completely Google-free, and in the occasional case that I need to use an app which requires Google services, I switch to the "GoogleMe" profile where I've installed those specific apps but they run within the protections that GrapheneOS implements around the Google Play framework/services. Gives me peace of mind. Then for anything administrative, I switch to the root/owner profile. These three profiles cover all my use-cases nicely.
Big fan of GrapheneOS. It helps me sleep better at night. A few tips getting started were really helpful, but otherwise it has been a very smooth and pain-free experience. This has been and will be my daily driver phone OS. After trying Cyanogenmod/LineageOS and Purism Librem5, and not being satisfied with those as my daily driver, this has hit the mark for me. Thank you, GrapheneOS team!
Posted Jul 29, 2025 2:53 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Jul 29, 2025 13:42 UTC (Tue)
by corbet (editor, #1)
[Link] (2 responses)
Posted Jul 29, 2025 14:20 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Certainly on my phone, some apps take over the whole screen but leave those in place (Contacts, for example, which Google has enshittified but never mind ...), while others (Kindle) take over the whole screen and require you to "swipe up" to make them re-appear - which is equally enshittified because Kindle has a nasty habit of detecting and hijacking the swipe!
Cheers,
Posted Jul 29, 2025 18:02 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Even if an app correctly handles the insets, you still have to swipe up to show the three-button bar before interacting with it.
It's freaking annoying. And can't be turned off.
GrapheneOS also has fixes for vulnerabilities Android does not have
Improved user profiles
Improved user profiles
And Graphene allows a lot more profiles.
But it allows you a bit more overlap between main profile and private profile, like copy / pasting, sharing photos. Except one or the other can be without play services if desired.
https://f-droid.org/en/packages/net.typeblog.shelter/
Clearing up some things
Google login?
https://auroraoss.com/
The Google login was required for the Play Store. I haven't tried Aurora.
Google login?
Google login?
Google login?
GrapheneOS & law enforcement
https://grapheneos.social/@GrapheneOS/114813613250805804
https://www.androidauthority.com/google-pixel-organized-c...
https://www.androidauthority.com/why-i-use-grapheneos-on-...
GrapheneOS & law enforcement
GrapheneOS & law enforcement
GrapheneOS & law enforcement
GrapheneOS & law enforcement
Attestation requirements
f-droid
Attestation requirements
Attestation requirements
https://old.reddit.com/r/degoogle/comments/1mau7yl/eu_age...
https://news.ycombinator.com/item?id=44705240
Attestation requirements
Ugly
What about transparency?
What about transparency?
What about transparency?
Hostile to root
Hostile to root
Hostile to root
Hostile to root
Graphene + Aurora (but no Google Play) here
Corrections/elaborations on some points
-https://github.com/GrapheneOS/platform_bionic/forks?inclu...
-https://github.com/GrapheneOS-Archive/legacy_bugtracker/i...
- App compatibility is a priority for the project and we are always working on maintaining/improving that.
- From our perspective, running an invasive app on GrapheneOS is much better than running it on a less secure, less private OS that doesn't provide the same amount of control.
- It's important to note that if hardening features break apps, there are toggles that can be used to make apps work again.
- A correction regarding the timeline for Android 16: the initial upstream release was on June 10th and our initial production release was on June 30. It usually takes us ~2 days, but took longer this time due to upstream dropping some device repositories, so porting took longer than usual. We did backport driver/firmware security patches to Android 15 before finalizing the Android 16 port.
- At the beginning of the article, it was said that GrapheneOS is an "Android rebuild". It would be more accurate to call it a fork of the Android Open Source Project (AOSP).
HeliBoard keyboard
It's an OpenBoard derivative available in F-Droid. I've been happily using it for 6 months now. At last a Free Software option that doesn't make me miserable (compared to Swiftkey I was using before, which was hard to move away from).
For the curious, here is the GrapheneOS project's fediverse response to this article.
How the project really feels about this article
How the project really feels about this article
How the project really feels about this article
Interesting, they also deleted my responses, before I gave up on it. What's there now is pretty far removed from what that conversation initially looked like. It's tempting to resurrect the whole thing out of my client history ... but I suspect I'll manage to resist.
How the project really feels about this article
How the project really feels about this article
How the project really feels about this article
PR doesn't just stand for "Pull Requests"
PR doesn't just stand for "Pull Requests"
big GrapheneOS fan
Edge-to-edge
Do you mean the Back/Home/Overview buttons at the bottom? There is a configuration option to get those back. I think it's a standard Android thing, not special to GrapheneOS.
Edge-to-edge
Edge-to-edge
Wol
Edge-to-edge