20 ms·

Experimental release of GrapheneOS for Pixel 9a

372 points by moelf 1y ago

JeremyBarbosa 1y ago
I was bit confused why this was notable, but the Pixel 9a just released Thursday. So this is an incredibly fast turnaround for a community OS.
- bitpush 1y ago
  They are starting from an OS that is made to work on these devices.
  - nzeid 1y ago
    ? As in the OS in question is GrapheneOS itself?
    - nofriend 1y ago
      i assume referring to aosp
      - nzeid 1y ago
        Right, and that would actually be a mountain and a monumental achievement. But one could argue that the team can move fast on 9a because they can piggyback existing (GrapheneOS) distros.
  - strcat 1y ago
    All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones. We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though. Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us. Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a). We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack. If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
    - haukem 1y ago
      Thank you for all the insights. Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now. Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google? Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.
      - strcat 1y ago
        > Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google? We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users. Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users. > Many of the security features you are using are already included in AOSP That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP. For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all. > Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? Yes, but you're wrong about where our privacy and security features come from.
  - crossroadsguy 1y ago
    Reminds me of iOS and iDevices and how even after months they keep stabilising and then they fail to stabilise and then they release the next version after a year with all those bugs intact and accumulated. In this case that OS is literally made for only those devices and vice-versa, in iron claw control of one control freak corporation that has a net worth more than GDPs many countries would nuke for. Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above. Respectfully, I hope that sunk in.
- CartwheelLinux 1y ago
  Incredibly fast. While the 9a and 9 pro are very similar, for comunity based development this is substantial. I am often very critial, but I must give props to the grapeneos team.
- tripdout 1y ago
  I think a lot of the work is in new device bringup, and given that they can start from official Pixel trees, it shouldn't be too much work to adapt them for whatever GrapheneOS-specific build processes they have, and then I'm assuming the rest of the GrapheneOS customizations are framework side which should be device agnostic. I guess they could have kernel changes for hardening, but not sure how easy or hard porting those would be - is the Pixel 9 series on a newer kernel version than say the Pixel 8?
  - strcat 1y ago
    GrapheneOS has various features requiring hardware integration. Our hardening features also uncover bugs across the code especially in drivers, especially the hardware memory tagging integration in our hardened_malloc project and the standard Linux kernel hardware memory tagging support we use in the kernel. Pixels are very similar to each other though so this work is largely but not entirely done for them. Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it. See https://news.ycombinator.com/item?id=43669913 https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025. Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
- mixmastamyk 1y ago
  Anyone know why drivers in this OS can't be ported to Linux, so it could support newer phones as well?
  - strcat 1y ago
    Android Open Source Project and operating systems based on it like GrapheneOS are Linux distributions. The kernel drivers are Linux kernel drivers. The userspace drivers are part of Android's Treble hardware abstraction layer providing forwards compatibility with future Android releases and SELinux-based sandboxing with the drivers split up into isolated processes. Most of the driver complexity is in userspace with most kernel drivers acting as shims between the isolated drivers and the hardware. It's done that way for practical reasons on Android but it's good for security. Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc. GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.
    - yjftsjthsd-h 1y ago
      > The kernel drivers are Linux kernel drivers. But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
- kowabungalow 1y ago
  Also, this is the first pixel after this announcement: https://news.ycombinator.com/item?id=43485950 https://news.ycombinator.com/item?id=43485950
  - codethief 1y ago
    Oh wow, how did I miss that! If strcat / Daniel Micay happens to pass by: How much will this impact future development of GrapheneO?
    - strcat 1y ago
      The changes are overstated in the media and has little impact on it. See https://news.ycombinator.com/item?id=43674145 https://news.ycombinator.com/item?id=43674145. We would benefit a lot from early access to quarterly and yearly releases but that hasn't ever been public and the AOSP main branch only provided the most recent changes for a few components, and not any of the ones we actually need most.
      - codethief 1y ago
        Thanks!
  - strcat 1y ago
    The changes are overstated and it really changes very little for GrapheneOS. See https://discuss.grapheneos.org/d/21315-explanation-of-recent-changes-to-aosp-and-the-lack-of-major-impact-on-grapheneos https://discuss.grapheneos.org/d/21315-explanation-of-recent.... Android already published the full source code for Stable releases but barely anything for Beta releases. They didn't publish anything for upcoming releases with support for new devices. AOSP main branch received most changes through the Stable releases being merged into it. Most components were developed internally. Certain components were developed publicly in AOSP so they had to repeatedly merge back and forth between the internal and public main branches. GrapheneOS would benefit from having early access to the monthly, quarterly and yearly releases as Android OEM partners do. The only benefit of having access to the main development branch would be the ability to backport more fixes than they do along with doing it earlier. We occasionally backported fixes from AOSP main for the few components developed publicly through it, which is what's going to be mostly going away. It was a big help to us as access to the upcoming quarterly and yearly releases would be. Monthly updates are too small for it to really matter but it'd still help. Also worth noting the monthly security patch backports (Android Security Bulletins) are a separate thing from the new OS release each month. Those are backports of many of the High and Critical severity patches to older Android versions, often a month or two after they were released in the actual OS releases each month which are the monthly, quarterly and yearly releases (it's one of the 3 each month, with 3 quarterly releases and 1 yearly release per year although Android 16 is coming earlier this year instead of a 3rd quarterly release).
OsrsNeedsf2P 1y ago
I installed GrapheneOS on my Pixel 4a after Google deleted the battery life[0], and while the initial move was frustrating with things not working, I've adapted and have a nice feeling of security while using my device again. It feels like it's mine, and I don't have to worry about who will spy on me or rug-pull me next. [0] https://grapheneos.social/@GrapheneOS/113917226566692707 https://grapheneos.social/@GrapheneOS/113917226566692707
- jeffbee 1y ago
  > deleted the battery life[0] Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
  - broodbucket 1y ago
    I don't have any idea what the situation is here and whether it's as black and white as you paint it, but regardless, surely something as significant as this should be presented to the user as an option rather than the manufacturer deciding for you that your phone that you own and paid for should now be unusable?
    - deleted 1y ago
      [deleted]
  - gpm 1y ago
    > or just hand you $50 if you prefer that. Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my-pixel-4a-then-stuck-it-to-me-too/ https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
  - tgsovlerkhgsel 1y ago
    The fixing offer is only valid in some locations, would require you to be without your phone for some time, and since Android still doesn't have anything that would be considered working backup and restore, I can't imagine many people being comfortable mailing their phone out for a replacement. The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).
aussieguy1234 1y ago
[flagged]
- gruez 1y ago
  Source?
  - iamtheworstdev 1y ago
    https://discuss.grapheneos.org/d/17097-is-it-still-the-case-emergency-services-location-access https://discuss.grapheneos.org/d/17097-is-it-still-the-case-...
    - nofriend 1y ago
      [flagged]
    - iamjackg 1y ago
      Sorry, I'm a bit confused. That link seem to state the opposite? The user is asking if 911 can still override the location settings on the phone, and the answer seems to be "yes."
  - aussieguy1234 1y ago
    Here in Australia, it didn't work the couple of times I called. The first question asked each time was which state I was in.
    - strcat 1y ago
      You probably don't have network-based location enabled. Satellite-based location doesn't work well indoors and takes a while to get a lock. Network-based location support was recently added to GrapheneOS and is opt-in. See https://grapheneos.org/features#network-location https://grapheneos.org/features#network-location and https://grapheneos.org/usage#network-location https://grapheneos.org/usage#network-location.
  - strcat 1y ago
blissofbeing 1y ago
I would like to root, but I like my Google pay.
- strcat 1y ago
  In many countries, there are tap-to-pay options permitting using GrapheneOS including Curve Pay and also the standard used by many European banks. US lacks an option but will hopefully get Curve Pay soon. Garmin Pay and Android Pay can be used via a Garmin or Android smart watch so that's what some of our US users do. Pixel Watch works fine paired with GrapheneOS with sandboxed Google Play. Note installing GrapheneOS doesn't involve rooting. Installing it uses an officially supported process and doesn't void the warranty. It preserves the standard security model and massively improves privacy and security on top of that (https://grapheneos.org/features https://grapheneos.org/features). It's largely the opposite of most other alternative Android-based operating systems are doing with security.
- rollcat 1y ago
  Genuinely curious, why do you need root access on your EDC phone? Personally I would stick with a throwaway for experimentation, so I'm curious about your motivation.
  - blissofbeing 1y ago
    To do things like turn off and on airplane mode when certain conditions are met with automate https://play.google.com/store/apps/details?id=com.llamalab.automate https://play.google.com/store/apps/details?id=com.llamalab.a... for example. There are work arounds but having a rooted phone is the easiest.
    - rollcat 1y ago
      I see. I get this out of the box on iOS via Shortcuts & automations, it's a part of the base OS and honestly pretty powerful. I get it that iOS is not for everyone, but at the very least it's a proof and an incentive for Android to implement this as well.
    - 1y ago
privacyking 1y ago
What's the next big feature being implemented? The last was the network location one.
- strcat 1y ago
  Feature development is going to be a bit slower for at least a couple months due to several of our core developers being temporarily unavailable. We're actively working on several major improvements including automatic generation of random passphrases and PINs, further improvements to VPN lockdown mode, per-app toggles for access to clipboard content from other apps to go beyond the existing restriction of only the focused app and keyboard being able to read it, etc. You can look through https://github.com/GrapheneOS/os-issue-tracker/issues https://github.com/GrapheneOS/os-issue-tracker/issues with the Feature type and enhancement label. GitHub unfortunately didn't provide a way to automatically migrate the older enhancement label to Feature type. We could use the API for it but haven't yet so you'll need to use both the old and new methods.
neodypsis 1y ago
Is there a GrapheneOS image for use with Android Emulator? I want to test an app on it but got no physical Pixel device.
- strcat 1y ago
  Many apps won't work in the Android emulator. Banking apps, etc. will detect it and ban it. Far more apps will ban the emulator than will ban GrapheneOS. We aren't aware of an app which would work in the Android emulator with a standard emulator image containing Google Play but wouldn't work with GrapheneOS. Nearly all Android apps work on GrapheneOS. It's nearly entirely just the subset which ban using any non-stock OS with the Play Integrity API which can't be used. We convinced a few banking apps to start allowing GrapheneOS via hardware attestation but the pace of banking apps integrating the Play Integrity API is unfortunately quite a bit faster than the pace we're convincing apps to support it after they do that. You can build it for the emulator. It's straightforward to do, but it requires a lot of disk space and it will take around 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We don't publish official releases for the emulator at the moment because it's not intended for production use and isn't really a good experience to use. We could start doing it, but it'd add some extra work and we'd be concerned about people misinterpreting what it's meant to provide. Emulator builds don't have the regular security model intact or OS updates, etc.
  - neodypsis 1y ago
    Thanks for the reply, yeah, my interest was to test compatibility when we add support for Play Integrity to our app.
    - strcat 1y ago
      Please read https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu.... It's possible to support GrapheneOS by using the Android hardware attestation API either as an alternative to the Play Integrity API or instead of it. By using the hardware attestation API, you can make a list of allowed key fingerprints for the SelfSigned boot state for non-Google-certified operating systems. We list all our current keys for non-end-of-life devices on that page. Recently, Swissquote used this approach to add support for GrapheneOS to their Yuh app and may be adding it to their main Swissquote app soon. You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/ https://discuss.grapheneos.org/.
64848374 1y ago
I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre offerings for their price range and the removal of the 3.5mm jack pushed many of the more techy users away — GrapheneOS's target audience. Not sure if I'd use GrapheneOS even if it was available on other devices though. Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
- hexagonwin 1y ago
  Huh? Pixels haven't had 3.5 jacks since Pixel 2 in 2017. wdym? GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
  - 64848374 1y ago
    2017? Maybe I'm getting old... Still, the point stands — the lack of a 3.5mm jack drives techy users away, and the Pixels just aren't very good for their price range today. > GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking. Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require. I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
    - sksrbWgbfK 1y ago
      > Nothing is stopping them from being more permissive Except for the fact that they don't want to be permissive to keep on being secure.
    - strcat 1y ago
      > Sure, because they picked a set of features exclusive to Pixels. No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed. > Nothing is stopping them from being more permissive about the security features they require. It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features? > I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless. It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.
gostsamo 1y ago
what is the screen reader story with Graphene? Is talkback supported or it is a victim of the security model?
- strcat 1y ago
  In general, we do not reduce app compatibility by removing any useful features. Our privacy improvements are implemented in a compatible way, like Contact Scopes pretending to be the Contacts permission having been granted but users choose which contacts can be seen and which data for those is visible. The only issues with app compatibility by default are due to app bugs including apps having bugs uncovered by exploit protection features. We have toggles to work around that including a simple per-app exploit protection compatibility mode changing the values of the finer grained ones. There are also a tiny subset of apps banning using a non-Google-certified OS, which are mainly a small subset of banking apps. We do have opt-in features which reduce compatibility with non-buggy apps, but they're all opt-in, such as the Dynamic Code Loading and native debugging restrictions. GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction. You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.
  - gostsamo 1y ago
    thanks, this was one of my main unknowns about the alternative oses.
  - Aachen 1y ago
    > We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to? I tried looking up more info about it but DDG only comes up with forum threads about workarounds
max_ 1y ago
How "private" is graphene? How much do I gain from switching to it instead of say, remaining on the Stock Android? Edit: This looks comprehensive — https://staging.grapheneos.org/features https://staging.grapheneos.org/features
- MrDrMcCoy 1y ago
  It's extremely private. It doesn't have Google services by default, but makes it easy to install them as unprivileged apps that - apart from giving you more control over what they can do and limiting certain access by default - work mostly exactly the same way as their privileged installs on other versions of Android. It also lets you disable Internet access privileges to any app that you don't want to have phone home. Beyond that, most of the other advantages will be less visible. They have hardened memory allocators that make various classes of security beaches significantly more difficult. There's a lot less superfluous background services eating resources. All that and more are listed on their website. It's well worth a read.
  - therein 1y ago
    That sounds really good. What are the downsides? How does it fare in terms of PlayIntegrity and SafetyNet etc?
    - 10729287 1y ago
      I may be wrong but I think most bank apps won't run on those devices. Anyone can confirm ?
      - switch007 1y ago
        YMMV. I'm on mobile but I think someone maintains a wiki page of compatibility. Remarkably, Nationwide (UK) runs perfectly even without Google services. (Except it doesn't poll for payment confirmations but that's understandable. They're always fetched when you open the app though. Or it could be my setup). It's actually quite shocking and it speaks to Nationwide as being a decent organisation. It's also not necessarily a downside. Having your banking app on your phone can be a risk of you often take your phone out in public The absolute blocker is Google Pay. That isn't supported
pinetroey 1y ago
I've been eying GrapheneOS for a few years. But there is one thing holding me back, Auto Call Recording. I'd love to make the switch.
- strcat 1y ago
  It's a planned feature but isn't a high priority. It's hard for us to get to it with all the other things we want to implement. We'll add it one day. We need to keep hiring more developers and expanding to do more.
  - sureglymop 1y ago
    I have a question you may be able to answer. Are contributions to GrapheneOS in general welcome? If yes, where would one start, is there a page about setting up a development environment or outlining a list of features/areas that could need work/help? I have quite a few spare Pixel phones that are currently just idling but I'd love to try building and installing GOS myself to start out.
- oth001 1y ago
  Isn't there an app for that?
  - gitaarik 1y ago
    https://f-droid.org/packages/com.github.axet.callrecorder https://f-droid.org/packages/com.github.axet.callrecorder
- RandomBacon 1y ago
  I use ACR Phone app with the APH app and removed Network permissions.
  - pinetroey 1y ago
    Does it record 2-way audio in good quality? Ear & speaker & Bluetooth
darkwater 1y ago
Off topic but related to Android replacement on phones, let see if anyone can help me: I have an old Xiaomi Mi 9SE in a drawer, and I would like it to give it to my daughter as a Spotify player and that's it. No phone, no camera, no browser. Just Spotify. What would be the best way to start? PostmarketOS doesn't support it, GrapheneOS is security-focused, LineageOS is basically a full-fledged Android, I don't know if I would be able to limit it as I would.
- tentacleuno 1y ago
  You might be able to use App pinning to stop them leaving the Spotify app...
- codethief 1y ago
  On LineageOS with a bit of work you can also remove built-in apps like browser, camera, etc.
0x38B 1y ago
The Pixel 9a is really tempting for someone like me who’s tired of living in Apple’s walled garden (1), but wants a decent device at a fair price that’ll be supported for a good long time - the Pixel 9a ticks all of those boxes. 1: Why? File management and getting files into apps is the #1 area where Android wins. For example, iOS has me copying or saving audiobooks into a folder only to import them into BookPlayer, whereas Android’s Smart Audiobook Player lets me copy my book to my audiobooks folder and hit ‘rescan’. Funnily enough, one of the only music apps on iOS that offers the same functionality - copy a folder into your library and rescan - is the same Neutron Player I used to use on Android. The interface is clunky, but that’s a small price to pay.
- piyuv 1y ago
  I wish I didn’t have to pay google of all companies to escape Apple.
  - Epa095 1y ago
    I wonder how much Google actually makes on these. I won't be surprised if they basically make nothing on them. It is a bit fun that seemingly the best way to de-google and de-apple yourself is to buy an actual Google device and install grapheneos on it.
notorandit 1y ago
I hope the so-called blobs have been replaced with unprivileged opensource versions. Otherwise privacy and security would be meaning basically nothing.
- strcat 1y ago
  Open source doesn't provide any magical privacy or security. iPhones have solid privacy and security despite being mostly closed source software. iPhones are the next best options for privacy and security in most ways. They have great privacy from apps and aren't awful at privacy from Apple particular if people use Advanced Data Program for iCloud, and they have solid security overall along with some useful settings for it. GrapheneOS of course provides better privacy from the OS services. We provide a full list of default connections made by the OS at https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections and none are made by the hardware without the OS prompting it. GrapheneOS also defends better against sophisticated real world attacks, and there's real world evidence for that from leaked capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB (XRY) along with some basic info about remote exploit sellers. All of the kernel drivers are open source, which would be the case for Snapdragon too. Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things. There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help. If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.
ram_rattle 1y ago
I wonder how they handle cellular and wifi part, lot of proprietary shit in that.
m1keil 1y ago
How is the camera quality on the GrapheneOS phones?
- celsoazevedo 1y ago
  GrapheneOS' own camera app doesn't have Google's propriety processing, so it's not as good as stock, but with Pixel devices, you can install the original Google Camera/Pixel Camera app and get the original camera quality.
  - strcat 1y ago
    GrapheneOS Camera does have hardware accelerated HDR+ and Night mode along with HDRnet and EIS for videos on Pixels. Photos in Pixel Camera look different because the HDR+ it uses by default is more aggressive resulting in higher contrast but a less natural look. Both are using HDR+ with hardware acceleration though. Videos are more similar and Night mode photos likely are too.
    - shaky-carrousel 1y ago
      But I think Pixel Camera does some kind of sharpening post-processing, because I get blurry images sometimes with GrapheneOS Camera while almost never with Pixel Camera.
- strcat 1y ago
  Camera quality is the same within the same app on either. Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it. GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time. Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
versluis 1y ago
I love GrapheneOS. The biggest downside is that Google integrity API block wireless payments in Google Pay. All Dutch banks now advertise to install Google pay for wireless payments. I've tried asking Google to support GrapheneOS but they told me to do a feature request. Which I did and got no reply to. I've contacted the consumer market authority and made a formal complaint since Google and Apple share effectively a contactless payments duopoly and decide which OS distributions get access. Those are closed source and usually bundled with a lot of spyware. I also explained how the Google integrity API might affect banking availability in the future (and already does for some banking apps). They took it very seriously and I hope to hear from them in the future.
- decide1000 1y ago
  Did you do your complaint at ACM? I want to follow your example
  - versluis 1y ago
    I did using their website form. It needs to be clear from the complaint that Google is violating fair market principles. They also like details about what exactly is happening and who is affected. That was why they called me after I filed the complaint.
    - Aachen 1y ago
      I would love to chip in and see if we can get this ball rolling, usually I feel like I'm the only person who cares or files AP/ACM/... complaints and then it's too small beans for them to care. I'd not submit the literal same thing again, but could you share what wording you've used? Specifically in this case I'd also not be sure whether this blocking of Graphene etc. is abuse of market power when there is another option on the market (Apple) and so it's not a monopoly There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile
      - versluis 1y ago
raffael_de 1y ago
What is the current conventional UX with GrapheneOS? Especially regarding: - Usability of taxi apps like: Uber, Grab, Bolt - Camera quality versus stock ROM
- adikso 1y ago
  Uber and Bolt apps works like normal. I don't know what is Grab. The default camera lacks post-processing tricks, but you can install Google Camera if you like (shouldn't be a privacy concern here with limited permissions).
  - raffael_de 1y ago
    Interesting. I used to have problems using such apps on LineageOS due to their dependence on this Google Push Messaging service (don't remember what it's called) and also dependence on Google Maps services. (Grab is like Uber/Bolt but used in different regions of the world.) Camera quality of LineageOS was really bad. A voyage was the catalyst for switching to iPhone as this seemed back then the best option to LineageOS and I couldn't risk not being able to use such logistically relevant apps. Especially in Asia you have to be ready to install and use whatever app is required and not being able to might be seriously handicapping.
    - sureglymop 1y ago
      On GrapheneOS, you can install Google play services in a sandboxed way (and if you want, in another user profile, work profile or private space) which can allow all these things to work seamlessly. Generally I've had way more problems with other custom roms and things like MicroG. I'd recommend to just try it out if you have an unused pixel phone. Imo it's very unlike any other custom rom in terms of the user experience.
  - strcat 1y ago
    GrapheneOS Camera does have HDR+ and Night mode on Pixels along with HDRnet and EIS for videos. Pixel Camera has more features and more aggressive HDR+.
- 1y ago
tiborsaas 1y ago
We should normalize having a "sceenshot" menu in the navigation again. Not their social, website has any. Is this a text based operating system?
- codethief 1y ago
  GrapheneOS looks almost exactly like AOSP and doesn't add any visual features, so screenshots would be somewhat pointless.
  - tiborsaas 1y ago
    It would answer my question properly if I'd seen that it looks just like the stock Android UI, so even though it's almost exactly the same, that's still quite valuable for me rather than pointless. I've also done some image search and it does change a bit with apps and they look quite good. So I'm still baffled why this aversion to images is decided. Or just overlooked maybe?
    - codethief 1y ago
      Probably just overlooked, yes. > it does change a bit with apps and they look quite good Hmm, I haven't noticed any difference. Which apps are you referring to?
      - tiborsaas 1y ago
        In this article there are a few screenshots with grayscale icons: https://9to5google.com/2024/04/16/grapheneos-review-de-googled-goodness-video/ https://9to5google.com/2024/04/16/grapheneos-review-de-googl... Is that the default?
        codethief 1y ago
        No, the grayscale icons are for built-in GrapheneOS apps only. Non-GOS apps look as they would on any other phone.
        1y ago
EffrafaxOfWug 1y ago
When installing graphene os I would consider very carefully if you want to relock the bootloader. In the past I have installed graphene os on my pixel 7a and a normal system update broke my system and made it unbootable. Because of the locked bootloader you can't reflash the os without wiping your data. It may be a very uncommon bug that may never happen to you, but honestly it shouldn't have happened to me either.
- sureglymop 1y ago
  I'd be interested in more specifics here. I've been in a few bootloops with GrapheneOS early on but I've always been able to get out of them by keeping cool and not prematurely trying to reflash and wipe. Eventually the phone always booted (I think that it's due to the A/B partition system where eventually the phone will try to boot the other "working" partition again. But sometimes this would take a while). It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.
  - EffrafaxOfWug 1y ago
    It was some time ago, so I unfortunately can't remember all the details. It occured during a normal system update that ran without problems at first, but when I rebooted the phone to finish the update it couldn't boot anymore (I can't remember the error messages). I don't know what exactly went wrong or was corrupted during the update. I definetly rebooted the phone multiple times and tried to fix the issue, but after some time I realized it was futile. Maybe there still was a way to salvage it, but I really can't tell in hindsight.
    - sureglymop 1y ago
      This has happened to me when the battery ran out during the reboot/upgrade. One time I had to let it charge and reboot for a good 30 minutes and eventually it booted again. I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.
sureglymop 1y ago
One cool thing about GrapheneOS when I recently got a new Pixel 9 was how easy it was to install it with just my older Pixel phone. Because the installer is WebUSB based it works in the Vanadium browser. I just connected the two phones together with a USB cable and could install the OS on my new phone from the browser. One currently missing thing is a "transfer" or backup functionality otherwise. There's really no good solution other than to manually port over applications and use their built-in import/export features if available.
- strcat 1y ago
  There's a built-in encrypted backup system in Settings > System > Backup. It works similarly to the Google Play device-to-device transfer system. It uses the same underlying device-to-device transfer mode for the Android backup infrastructure and should back up exactly the same data as the Google Play transfer system moves. It backs up a lot more than Google Play cloud backups because it uses device-to-device mode.
  - sureglymop 1y ago
    So, is the current recommendation to create such a backup to an external storage and then restore it on a new device? There is currently no direct device-to-device transfer feature using this, correct?
NoImmatureAdHom 1y ago
I think GrapheneOS is one of the most important projects going. Many people walk around with all-purpose spying devices in their pocket, oblivious to how much power they are giving up. They have no control over these devices, and they don't even understand. GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics. Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?
- strcat 1y ago
  We plan to include a sensor kill switch on our own future hardware but the value is lower than most people believe on one of their primary computing devices. If it was successfully exploited, an attacker would get all of the data including documents, photos, videos, browser history, login sessions, passwords and much more. They'd also have control of the sensors whenever they're enabled including any calls, etc. A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.
  - NoImmatureAdHom 1y ago
    Thanks for the thoughtful reply! One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you. I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on. Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off. Thank you again for your thoughtful reply and your work.
mystified5016 1y ago
I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own. Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works. Graphene thinks you can't be trusted with your own device. But don't worry, they definitely know what's best for you and it's a totally different kind of control from what Google has. Really, just trust them, it's totally fine, promise. I switched to Lineage after a few months.
- gruez 1y ago
  >I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own. What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you. >Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works. That's fine. The homepage of grapheneos says: "The private and secure mobile operating system with Android app compatibility" Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http:// http://...` from getting pwned.
  - NotPractical 1y ago
    > "security" and "giving users a say in how their phone works" are diametrically opposed Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there. I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be. > It's not recommended, but you can install magisk + root if you really wanted to. Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent. FWIW I don't agree with the OP, just replying to your comment in particular.
miramba 1y ago
I installed GrapheneOS on a spare Pixel 4a recently...through a browser window. I thought at first that I had to download a firmware flasher or something, but no, it updated the device from that webpage! That was impressive. The other thing I would like to mention: Chromium is installed, so PWAs can be installed instead of connecting to a sandboxed google play or something. The PWAs I tried looked just like on an iPhone or desktop. Yes, we are far, far away from PWAs being a complete replacement. But it is in theory possible: An independent mobile OS with platform-independent apps. No Apple/Google ID needed, no appstores. That was the point of this test install, and it worked.
Hj8Rd2Qw 1y ago
[dead]

372 points by moelf 1y ago

I was bit confused why this was notable, but the Pixel 9a just released Thursday. So this is an incredibly fast turnaround for a community OS.

bitpush 1y ago
They are starting from an OS that is made to work on these devices.
- nzeid 1y ago
  ? As in the OS in question is GrapheneOS itself?
  - nofriend 1y ago
    i assume referring to aosp
    - nzeid 1y ago
      Right, and that would actually be a mountain and a monumental achievement. But one could argue that the team can move fast on 9a because they can piggyback existing (GrapheneOS) distros.
- strcat 1y ago
  All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones. We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though. Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us. Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a). We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack. If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
  - haukem 1y ago
    Thank you for all the insights. Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now. Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google? Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.
    - strcat 1y ago
      > Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google? We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users. Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users. > Many of the security features you are using are already included in AOSP That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP. For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all. > Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? Yes, but you're wrong about where our privacy and security features come from.
- crossroadsguy 1y ago
  Reminds me of iOS and iDevices and how even after months they keep stabilising and then they fail to stabilise and then they release the next version after a year with all those bugs intact and accumulated. In this case that OS is literally made for only those devices and vice-versa, in iron claw control of one control freak corporation that has a net worth more than GDPs many countries would nuke for. Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above. Respectfully, I hope that sunk in.
CartwheelLinux 1y ago
Incredibly fast. While the 9a and 9 pro are very similar, for comunity based development this is substantial. I am often very critial, but I must give props to the grapeneos team.
tripdout 1y ago
I think a lot of the work is in new device bringup, and given that they can start from official Pixel trees, it shouldn't be too much work to adapt them for whatever GrapheneOS-specific build processes they have, and then I'm assuming the rest of the GrapheneOS customizations are framework side which should be device agnostic. I guess they could have kernel changes for hardening, but not sure how easy or hard porting those would be - is the Pixel 9 series on a newer kernel version than say the Pixel 8?
- strcat 1y ago
  GrapheneOS has various features requiring hardware integration. Our hardening features also uncover bugs across the code especially in drivers, especially the hardware memory tagging integration in our hardened_malloc project and the standard Linux kernel hardware memory tagging support we use in the kernel. Pixels are very similar to each other though so this work is largely but not entirely done for them. Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it. See https://news.ycombinator.com/item?id=43669913 https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025. Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
mixmastamyk 1y ago
Anyone know why drivers in this OS can't be ported to Linux, so it could support newer phones as well?
- strcat 1y ago
  Android Open Source Project and operating systems based on it like GrapheneOS are Linux distributions. The kernel drivers are Linux kernel drivers. The userspace drivers are part of Android's Treble hardware abstraction layer providing forwards compatibility with future Android releases and SELinux-based sandboxing with the drivers split up into isolated processes. Most of the driver complexity is in userspace with most kernel drivers acting as shims between the isolated drivers and the hardware. It's done that way for practical reasons on Android but it's good for security. Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc. GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.
  - yjftsjthsd-h 1y ago
    > The kernel drivers are Linux kernel drivers. But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
kowabungalow 1y ago
Also, this is the first pixel after this announcement: https://news.ycombinator.com/item?id=43485950 https://news.ycombinator.com/item?id=43485950
- codethief 1y ago
  Oh wow, how did I miss that! If strcat / Daniel Micay happens to pass by: How much will this impact future development of GrapheneO?
  - strcat 1y ago
    The changes are overstated in the media and has little impact on it. See https://news.ycombinator.com/item?id=43674145 https://news.ycombinator.com/item?id=43674145. We would benefit a lot from early access to quarterly and yearly releases but that hasn't ever been public and the AOSP main branch only provided the most recent changes for a few components, and not any of the ones we actually need most.
    - codethief 1y ago
      Thanks!
- strcat 1y ago
  The changes are overstated and it really changes very little for GrapheneOS. See https://discuss.grapheneos.org/d/21315-explanation-of-recent-changes-to-aosp-and-the-lack-of-major-impact-on-grapheneos https://discuss.grapheneos.org/d/21315-explanation-of-recent.... Android already published the full source code for Stable releases but barely anything for Beta releases. They didn't publish anything for upcoming releases with support for new devices. AOSP main branch received most changes through the Stable releases being merged into it. Most components were developed internally. Certain components were developed publicly in AOSP so they had to repeatedly merge back and forth between the internal and public main branches. GrapheneOS would benefit from having early access to the monthly, quarterly and yearly releases as Android OEM partners do. The only benefit of having access to the main development branch would be the ability to backport more fixes than they do along with doing it earlier. We occasionally backported fixes from AOSP main for the few components developed publicly through it, which is what's going to be mostly going away. It was a big help to us as access to the upcoming quarterly and yearly releases would be. Monthly updates are too small for it to really matter but it'd still help. Also worth noting the monthly security patch backports (Android Security Bulletins) are a separate thing from the new OS release each month. Those are backports of many of the High and Critical severity patches to older Android versions, often a month or two after they were released in the actual OS releases each month which are the monthly, quarterly and yearly releases (it's one of the 3 each month, with 3 quarterly releases and 1 yearly release per year although Android 16 is coming earlier this year instead of a 3rd quarterly release).

OsrsNeedsf2P 1y ago

I installed GrapheneOS on my Pixel 4a after Google deleted the battery life[0], and while the initial move was frustrating with things not working, I've adapted and have a nice feeling of security while using my device again. It feels like it's mine, and I don't have to worry about who will spy on me or rug-pull me next. [0] https://grapheneos.social/@GrapheneOS/113917226566692707 https://grapheneos.social/@GrapheneOS/113917226566692707

jeffbee 1y ago
> deleted the battery life[0] Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
- broodbucket 1y ago
  I don't have any idea what the situation is here and whether it's as black and white as you paint it, but regardless, surely something as significant as this should be presented to the user as an option rather than the manufacturer deciding for you that your phone that you own and paid for should now be unusable?
  - deleted 1y ago
    [deleted]
- gpm 1y ago
  > or just hand you $50 if you prefer that. Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my-pixel-4a-then-stuck-it-to-me-too/ https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
- tgsovlerkhgsel 1y ago
  The fixing offer is only valid in some locations, would require you to be without your phone for some time, and since Android still doesn't have anything that would be considered working backup and restore, I can't imagine many people being comfortable mailing their phone out for a replacement. The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).

aussieguy1234 1y ago

[flagged]

gruez 1y ago
Source?
- iamtheworstdev 1y ago
  https://discuss.grapheneos.org/d/17097-is-it-still-the-case-emergency-services-location-access https://discuss.grapheneos.org/d/17097-is-it-still-the-case-...
  - nofriend 1y ago
    [flagged]
  - iamjackg 1y ago
    Sorry, I'm a bit confused. That link seem to state the opposite? The user is asking if 911 can still override the location settings on the phone, and the answer seems to be "yes."
- aussieguy1234 1y ago
  Here in Australia, it didn't work the couple of times I called. The first question asked each time was which state I was in.
  - strcat 1y ago
    You probably don't have network-based location enabled. Satellite-based location doesn't work well indoors and takes a while to get a lock. Network-based location support was recently added to GrapheneOS and is opt-in. See https://grapheneos.org/features#network-location https://grapheneos.org/features#network-location and https://grapheneos.org/usage#network-location https://grapheneos.org/usage#network-location.
- strcat 1y ago

blissofbeing 1y ago

I would like to root, but I like my Google pay.

strcat 1y ago
In many countries, there are tap-to-pay options permitting using GrapheneOS including Curve Pay and also the standard used by many European banks. US lacks an option but will hopefully get Curve Pay soon. Garmin Pay and Android Pay can be used via a Garmin or Android smart watch so that's what some of our US users do. Pixel Watch works fine paired with GrapheneOS with sandboxed Google Play. Note installing GrapheneOS doesn't involve rooting. Installing it uses an officially supported process and doesn't void the warranty. It preserves the standard security model and massively improves privacy and security on top of that (https://grapheneos.org/features https://grapheneos.org/features). It's largely the opposite of most other alternative Android-based operating systems are doing with security.
rollcat 1y ago
Genuinely curious, why do you need root access on your EDC phone? Personally I would stick with a throwaway for experimentation, so I'm curious about your motivation.
- blissofbeing 1y ago
  To do things like turn off and on airplane mode when certain conditions are met with automate https://play.google.com/store/apps/details?id=com.llamalab.automate https://play.google.com/store/apps/details?id=com.llamalab.a... for example. There are work arounds but having a rooted phone is the easiest.
  - rollcat 1y ago
    I see. I get this out of the box on iOS via Shortcuts & automations, it's a part of the base OS and honestly pretty powerful. I get it that iOS is not for everyone, but at the very least it's a proof and an incentive for Android to implement this as well.
  - 1y ago

privacyking 1y ago

What's the next big feature being implemented? The last was the network location one.

strcat 1y ago
Feature development is going to be a bit slower for at least a couple months due to several of our core developers being temporarily unavailable. We're actively working on several major improvements including automatic generation of random passphrases and PINs, further improvements to VPN lockdown mode, per-app toggles for access to clipboard content from other apps to go beyond the existing restriction of only the focused app and keyboard being able to read it, etc. You can look through https://github.com/GrapheneOS/os-issue-tracker/issues https://github.com/GrapheneOS/os-issue-tracker/issues with the Feature type and enhancement label. GitHub unfortunately didn't provide a way to automatically migrate the older enhancement label to Feature type. We could use the API for it but haven't yet so you'll need to use both the old and new methods.

neodypsis 1y ago

Is there a GrapheneOS image for use with Android Emulator? I want to test an app on it but got no physical Pixel device.

strcat 1y ago
Many apps won't work in the Android emulator. Banking apps, etc. will detect it and ban it. Far more apps will ban the emulator than will ban GrapheneOS. We aren't aware of an app which would work in the Android emulator with a standard emulator image containing Google Play but wouldn't work with GrapheneOS. Nearly all Android apps work on GrapheneOS. It's nearly entirely just the subset which ban using any non-stock OS with the Play Integrity API which can't be used. We convinced a few banking apps to start allowing GrapheneOS via hardware attestation but the pace of banking apps integrating the Play Integrity API is unfortunately quite a bit faster than the pace we're convincing apps to support it after they do that. You can build it for the emulator. It's straightforward to do, but it requires a lot of disk space and it will take around 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We don't publish official releases for the emulator at the moment because it's not intended for production use and isn't really a good experience to use. We could start doing it, but it'd add some extra work and we'd be concerned about people misinterpreting what it's meant to provide. Emulator builds don't have the regular security model intact or OS updates, etc.
- neodypsis 1y ago
  Thanks for the reply, yeah, my interest was to test compatibility when we add support for Play Integrity to our app.
  - strcat 1y ago
    Please read https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu.... It's possible to support GrapheneOS by using the Android hardware attestation API either as an alternative to the Play Integrity API or instead of it. By using the hardware attestation API, you can make a list of allowed key fingerprints for the SelfSigned boot state for non-Google-certified operating systems. We list all our current keys for non-end-of-life devices on that page. Recently, Swissquote used this approach to add support for GrapheneOS to their Yuh app and may be adding it to their main Swissquote app soon. You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/ https://discuss.grapheneos.org/.

64848374 1y ago

I feel like GrapheneOS shot itself in the foot, being exclusive to Pixel phones. Pixel phones were great, in the past, but now they're mediocre offerings for their price range and the removal of the 3.5mm jack pushed many of the more techy users away — GrapheneOS's target audience. Not sure if I'd use GrapheneOS even if it was available on other devices though. Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.

hexagonwin 1y ago
Huh? Pixels haven't had 3.5 jacks since Pixel 2 in 2017. wdym? GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
- 64848374 1y ago
  2017? Maybe I'm getting old... Still, the point stands — the lack of a 3.5mm jack drives techy users away, and the Pixels just aren't very good for their price range today. > GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking. Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require. I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
  - sksrbWgbfK 1y ago
    > Nothing is stopping them from being more permissive Except for the fact that they don't want to be permissive to keep on being secure.
  - strcat 1y ago
    > Sure, because they picked a set of features exclusive to Pixels. No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed. > Nothing is stopping them from being more permissive about the security features they require. It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features? > I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless. It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.

gostsamo 1y ago

what is the screen reader story with Graphene? Is talkback supported or it is a victim of the security model?

strcat 1y ago
In general, we do not reduce app compatibility by removing any useful features. Our privacy improvements are implemented in a compatible way, like Contact Scopes pretending to be the Contacts permission having been granted but users choose which contacts can be seen and which data for those is visible. The only issues with app compatibility by default are due to app bugs including apps having bugs uncovered by exploit protection features. We have toggles to work around that including a simple per-app exploit protection compatibility mode changing the values of the finer grained ones. There are also a tiny subset of apps banning using a non-Google-certified OS, which are mainly a small subset of banking apps. We do have opt-in features which reduce compatibility with non-buggy apps, but they're all opt-in, such as the Dynamic Code Loading and native debugging restrictions. GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction. You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.
- gostsamo 1y ago
  thanks, this was one of my main unknowns about the alternative oses.
- Aachen 1y ago
  > We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to? I tried looking up more info about it but DDG only comes up with forum threads about workarounds

max_ 1y ago

How "private" is graphene? How much do I gain from switching to it instead of say, remaining on the Stock Android? Edit: This looks comprehensive — https://staging.grapheneos.org/features https://staging.grapheneos.org/features

MrDrMcCoy 1y ago
It's extremely private. It doesn't have Google services by default, but makes it easy to install them as unprivileged apps that - apart from giving you more control over what they can do and limiting certain access by default - work mostly exactly the same way as their privileged installs on other versions of Android. It also lets you disable Internet access privileges to any app that you don't want to have phone home. Beyond that, most of the other advantages will be less visible. They have hardened memory allocators that make various classes of security beaches significantly more difficult. There's a lot less superfluous background services eating resources. All that and more are listed on their website. It's well worth a read.
- therein 1y ago
  That sounds really good. What are the downsides? How does it fare in terms of PlayIntegrity and SafetyNet etc?
  - 10729287 1y ago
    I may be wrong but I think most bank apps won't run on those devices. Anyone can confirm ?
    - switch007 1y ago
      YMMV. I'm on mobile but I think someone maintains a wiki page of compatibility. Remarkably, Nationwide (UK) runs perfectly even without Google services. (Except it doesn't poll for payment confirmations but that's understandable. They're always fetched when you open the app though. Or it could be my setup). It's actually quite shocking and it speaks to Nationwide as being a decent organisation. It's also not necessarily a downside. Having your banking app on your phone can be a risk of you often take your phone out in public The absolute blocker is Google Pay. That isn't supported

pinetroey 1y ago

I've been eying GrapheneOS for a few years. But there is one thing holding me back, Auto Call Recording. I'd love to make the switch.

strcat 1y ago
It's a planned feature but isn't a high priority. It's hard for us to get to it with all the other things we want to implement. We'll add it one day. We need to keep hiring more developers and expanding to do more.
- sureglymop 1y ago
  I have a question you may be able to answer. Are contributions to GrapheneOS in general welcome? If yes, where would one start, is there a page about setting up a development environment or outlining a list of features/areas that could need work/help? I have quite a few spare Pixel phones that are currently just idling but I'd love to try building and installing GOS myself to start out.
oth001 1y ago
Isn't there an app for that?
- gitaarik 1y ago
  https://f-droid.org/packages/com.github.axet.callrecorder https://f-droid.org/packages/com.github.axet.callrecorder
RandomBacon 1y ago
I use ACR Phone app with the APH app and removed Network permissions.
- pinetroey 1y ago
  Does it record 2-way audio in good quality? Ear & speaker & Bluetooth

darkwater 1y ago

Off topic but related to Android replacement on phones, let see if anyone can help me: I have an old Xiaomi Mi 9SE in a drawer, and I would like it to give it to my daughter as a Spotify player and that's it. No phone, no camera, no browser. Just Spotify. What would be the best way to start? PostmarketOS doesn't support it, GrapheneOS is security-focused, LineageOS is basically a full-fledged Android, I don't know if I would be able to limit it as I would.

tentacleuno 1y ago
You might be able to use App pinning to stop them leaving the Spotify app...
codethief 1y ago
On LineageOS with a bit of work you can also remove built-in apps like browser, camera, etc.

0x38B 1y ago

The Pixel 9a is really tempting for someone like me who’s tired of living in Apple’s walled garden (1), but wants a decent device at a fair price that’ll be supported for a good long time - the Pixel 9a ticks all of those boxes. 1: Why? File management and getting files into apps is the #1 area where Android wins. For example, iOS has me copying or saving audiobooks into a folder only to import them into BookPlayer, whereas Android’s Smart Audiobook Player lets me copy my book to my audiobooks folder and hit ‘rescan’. Funnily enough, one of the only music apps on iOS that offers the same functionality - copy a folder into your library and rescan - is the same Neutron Player I used to use on Android. The interface is clunky, but that’s a small price to pay.

piyuv 1y ago
I wish I didn’t have to pay google of all companies to escape Apple.
- Epa095 1y ago
  I wonder how much Google actually makes on these. I won't be surprised if they basically make nothing on them. It is a bit fun that seemingly the best way to de-google and de-apple yourself is to buy an actual Google device and install grapheneos on it.

notorandit 1y ago

I hope the so-called blobs have been replaced with unprivileged opensource versions. Otherwise privacy and security would be meaning basically nothing.

strcat 1y ago
Open source doesn't provide any magical privacy or security. iPhones have solid privacy and security despite being mostly closed source software. iPhones are the next best options for privacy and security in most ways. They have great privacy from apps and aren't awful at privacy from Apple particular if people use Advanced Data Program for iCloud, and they have solid security overall along with some useful settings for it. GrapheneOS of course provides better privacy from the OS services. We provide a full list of default connections made by the OS at https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections and none are made by the hardware without the OS prompting it. GrapheneOS also defends better against sophisticated real world attacks, and there's real world evidence for that from leaked capabilities of Cellebrite, Magnet Forensics (Graykey) and MSAB (XRY) along with some basic info about remote exploit sellers. All of the kernel drivers are open source, which would be the case for Snapdragon too. Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things. There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help. If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.

ram_rattle 1y ago

I wonder how they handle cellular and wifi part, lot of proprietary shit in that.

m1keil 1y ago

How is the camera quality on the GrapheneOS phones?

celsoazevedo 1y ago
GrapheneOS' own camera app doesn't have Google's propriety processing, so it's not as good as stock, but with Pixel devices, you can install the original Google Camera/Pixel Camera app and get the original camera quality.
- strcat 1y ago
  GrapheneOS Camera does have hardware accelerated HDR+ and Night mode along with HDRnet and EIS for videos on Pixels. Photos in Pixel Camera look different because the HDR+ it uses by default is more aggressive resulting in higher contrast but a less natural look. Both are using HDR+ with hardware acceleration though. Videos are more similar and Night mode photos likely are too.
  - shaky-carrousel 1y ago
    But I think Pixel Camera does some kind of sharpening post-processing, because I get blurry images sometimes with GrapheneOS Camera while almost never with Pixel Camera.
strcat 1y ago
Camera quality is the same within the same app on either. Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it. GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time. Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.

versluis 1y ago

I love GrapheneOS. The biggest downside is that Google integrity API block wireless payments in Google Pay. All Dutch banks now advertise to install Google pay for wireless payments. I've tried asking Google to support GrapheneOS but they told me to do a feature request. Which I did and got no reply to. I've contacted the consumer market authority and made a formal complaint since Google and Apple share effectively a contactless payments duopoly and decide which OS distributions get access. Those are closed source and usually bundled with a lot of spyware. I also explained how the Google integrity API might affect banking availability in the future (and already does for some banking apps). They took it very seriously and I hope to hear from them in the future.

decide1000 1y ago
Did you do your complaint at ACM? I want to follow your example
- versluis 1y ago
  I did using their website form. It needs to be clear from the complaint that Google is violating fair market principles. They also like details about what exactly is happening and who is affected. That was why they called me after I filed the complaint.
  - Aachen 1y ago
    I would love to chip in and see if we can get this ball rolling, usually I feel like I'm the only person who cares or files AP/ACM/... complaints and then it's too small beans for them to care. I'd not submit the literal same thing again, but could you share what wording you've used? Specifically in this case I'd also not be sure whether this blocking of Graphene etc. is abuse of market power when there is another option on the market (Apple) and so it's not a monopoly There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile
    - versluis 1y ago

raffael_de 1y ago

What is the current conventional UX with GrapheneOS? Especially regarding: - Usability of taxi apps like: Uber, Grab, Bolt - Camera quality versus stock ROM

adikso 1y ago
Uber and Bolt apps works like normal. I don't know what is Grab. The default camera lacks post-processing tricks, but you can install Google Camera if you like (shouldn't be a privacy concern here with limited permissions).
- raffael_de 1y ago
  Interesting. I used to have problems using such apps on LineageOS due to their dependence on this Google Push Messaging service (don't remember what it's called) and also dependence on Google Maps services. (Grab is like Uber/Bolt but used in different regions of the world.) Camera quality of LineageOS was really bad. A voyage was the catalyst for switching to iPhone as this seemed back then the best option to LineageOS and I couldn't risk not being able to use such logistically relevant apps. Especially in Asia you have to be ready to install and use whatever app is required and not being able to might be seriously handicapping.
  - sureglymop 1y ago
    On GrapheneOS, you can install Google play services in a sandboxed way (and if you want, in another user profile, work profile or private space) which can allow all these things to work seamlessly. Generally I've had way more problems with other custom roms and things like MicroG. I'd recommend to just try it out if you have an unused pixel phone. Imo it's very unlike any other custom rom in terms of the user experience.
- strcat 1y ago
  GrapheneOS Camera does have HDR+ and Night mode on Pixels along with HDRnet and EIS for videos. Pixel Camera has more features and more aggressive HDR+.
1y ago

tiborsaas 1y ago

We should normalize having a "sceenshot" menu in the navigation again. Not their social, website has any. Is this a text based operating system?

codethief 1y ago
GrapheneOS looks almost exactly like AOSP and doesn't add any visual features, so screenshots would be somewhat pointless.
- tiborsaas 1y ago
  It would answer my question properly if I'd seen that it looks just like the stock Android UI, so even though it's almost exactly the same, that's still quite valuable for me rather than pointless. I've also done some image search and it does change a bit with apps and they look quite good. So I'm still baffled why this aversion to images is decided. Or just overlooked maybe?
  - codethief 1y ago
    Probably just overlooked, yes. > it does change a bit with apps and they look quite good Hmm, I haven't noticed any difference. Which apps are you referring to?
    - tiborsaas 1y ago
      In this article there are a few screenshots with grayscale icons: https://9to5google.com/2024/04/16/grapheneos-review-de-googled-goodness-video/ https://9to5google.com/2024/04/16/grapheneos-review-de-googl... Is that the default?
      - codethief 1y ago
        No, the grayscale icons are for built-in GrapheneOS apps only. Non-GOS apps look as they would on any other phone.
      - 1y ago

EffrafaxOfWug 1y ago

When installing graphene os I would consider very carefully if you want to relock the bootloader. In the past I have installed graphene os on my pixel 7a and a normal system update broke my system and made it unbootable. Because of the locked bootloader you can't reflash the os without wiping your data. It may be a very uncommon bug that may never happen to you, but honestly it shouldn't have happened to me either.

sureglymop 1y ago
I'd be interested in more specifics here. I've been in a few bootloops with GrapheneOS early on but I've always been able to get out of them by keeping cool and not prematurely trying to reflash and wipe. Eventually the phone always booted (I think that it's due to the A/B partition system where eventually the phone will try to boot the other "working" partition again. But sometimes this would take a while). It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.
- EffrafaxOfWug 1y ago
  It was some time ago, so I unfortunately can't remember all the details. It occured during a normal system update that ran without problems at first, but when I rebooted the phone to finish the update it couldn't boot anymore (I can't remember the error messages). I don't know what exactly went wrong or was corrupted during the update. I definetly rebooted the phone multiple times and tried to fix the issue, but after some time I realized it was futile. Maybe there still was a way to salvage it, but I really can't tell in hindsight.
  - sureglymop 1y ago
    This has happened to me when the battery ran out during the reboot/upgrade. One time I had to let it charge and reboot for a good 30 minutes and eventually it booted again. I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.

sureglymop 1y ago

One cool thing about GrapheneOS when I recently got a new Pixel 9 was how easy it was to install it with just my older Pixel phone. Because the installer is WebUSB based it works in the Vanadium browser. I just connected the two phones together with a USB cable and could install the OS on my new phone from the browser. One currently missing thing is a "transfer" or backup functionality otherwise. There's really no good solution other than to manually port over applications and use their built-in import/export features if available.

strcat 1y ago
There's a built-in encrypted backup system in Settings > System > Backup. It works similarly to the Google Play device-to-device transfer system. It uses the same underlying device-to-device transfer mode for the Android backup infrastructure and should back up exactly the same data as the Google Play transfer system moves. It backs up a lot more than Google Play cloud backups because it uses device-to-device mode.
- sureglymop 1y ago
  So, is the current recommendation to create such a backup to an external storage and then restore it on a new device? There is currently no direct device-to-device transfer feature using this, correct?

NoImmatureAdHom 1y ago

I think GrapheneOS is one of the most important projects going. Many people walk around with all-purpose spying devices in their pocket, oblivious to how much power they are giving up. They have no control over these devices, and they don't even understand. GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics. Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?

strcat 1y ago
We plan to include a sensor kill switch on our own future hardware but the value is lower than most people believe on one of their primary computing devices. If it was successfully exploited, an attacker would get all of the data including documents, photos, videos, browser history, login sessions, passwords and much more. They'd also have control of the sensors whenever they're enabled including any calls, etc. A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.
- NoImmatureAdHom 1y ago
  Thanks for the thoughtful reply! One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you. I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on. Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off. Thank you again for your thoughtful reply and your work.

mystified5016 1y ago

I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own. Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works. Graphene thinks you can't be trusted with your own device. But don't worry, they definitely know what's best for you and it's a totally different kind of control from what Google has. Really, just trust them, it's totally fine, promise. I switched to Lineage after a few months.

gruez 1y ago
>I really wanted to like Graphene, but it feels more locked down than stock android. The primary reason I want a custom OS in the first place is that I want to control the device I own. What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you. >Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works. That's fine. The homepage of grapheneos says: "The private and secure mobile operating system with Android app compatibility" Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http:// http://...` from getting pwned.
- NotPractical 1y ago
  > "security" and "giving users a say in how their phone works" are diametrically opposed Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there. I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be. > It's not recommended, but you can install magisk + root if you really wanted to. Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent. FWIW I don't agree with the OP, just replying to your comment in particular.

miramba 1y ago

I installed GrapheneOS on a spare Pixel 4a recently...through a browser window. I thought at first that I had to download a firmware flasher or something, but no, it updated the device from that webpage! That was impressive. The other thing I would like to mention: Chromium is installed, so PWAs can be installed instead of connecting to a sandboxed google play or something. The PWAs I tried looked just like on an iPhone or desktop. Yes, we are far, far away from PWAs being a complete replacement. But it is in theory possible: An independent mobile OS with platform-independent apps. No Apple/Google ID needed, no appstores. That was the point of this test install, and it worked.

Hj8Rd2Qw 1y ago

[dead]