grapheneos

The hardened_malloc project has performance vs. security configuration. It's used in a very security-oriented configuration in GrapheneOS. GrapheneOS could offer a performance vs. security toggle for this but hasn't yet included one since there are rarely apps with any noticeable performance difference. Android apps are mostly written in Java/Kotlin where it makes no difference. There are often specific uses of optimized C, C++ or Rust code where it makes little difference. It's rare for an app to be heavily impacted by malloc performance as if it's a malloc microbenchmark, and even in that case the overhead is typically quite reasonable. OsmAnd is doing something very strange in a certain configuration.

No, it does not have "a bunch of performance issues". It has carefully considered performance vs. security compromises which are largely configurable. GrapheneOS uses hardened_malloc in a very security-oriented configuration and has the option to disable it per-app if there's ever a compatibility or performance issue. GrapheneOS could also offer another toggle for setting it to a performance mode where it isn't significantly slower than Scudo either via dynamic configuration or a 2nd build of hardened_malloc with a lighter configuration. Most overhead is from slab allocation quarantines which are optional.

The hardened allocator doesn't wrap malloc but rather is the default malloc implementation on GrapheneOS with a per-app opt-out toggle. It makes no substantial difference for overall OS performance but there are definitely apps where it matters. OsmAnd works fine for most users without disabling it though.

The feature protects the app from exploits and doesn't provide any additional security for the OS from the app. It's worth noting most users are having no issues running OsmAnd with hardened_malloc.

> What is the point of this hardening feature if you got to disable it ?

It doesn't have to be disabled. Most users are saying OsmAnd runs fine for them with the default of hardened_malloc being enabled. There was no need to disable the other hardening features. A subset of users are experiencing slow performance in the OpenGL rendering mode with hardened_malloc enabled. It's likely due to the implementation in the app doing something quite inefficient which hasn't yet been identified. The hardened_malloc configuration in GrapheneOS is heavily oriented to security and has more overhead than the lite configuration. We could offer a performance vs. security mode for it but it usually makes no major difference and has a toggle for any case it does.

Only a tiny subset of apps require Play Integrity levels and a growing number of those are explicitly permitting GrapheneOS.

No, it means Pixels will have exclusive features in third party apps for 2 separate spans of 3 months every year.

Samsung is already largely free from Google's egregiously anti-competitive licensing rules for Google Mobile Services. Why do you think it's going to survive for the rest? It's already unsustainable to have different rules for the largest OEM and that's without even taking into account future court victories similar to what happened in South Korea.

People can buy Pixels with GrapheneOS preinstalled from a bunch of companies despite it not being shipped that way from the factory.

Pixels are currently the only devices providing the required updates and hardware security features. There will be at least one Motorola flagship with GrapheneOS support in 2027 meeting the same requirements. It will expand to more Motorola devices from there. iOS only runs on iPhones but that's hardly a barrier to adoption for it. Pixels aren't quite broadly available enough and it will take time before we can support lower end Motorola devices in the same price range as an 'a' series Pixel.

The vast majority of Android apps do work. Banking apps are a special case where around 10% don't work due to banning using a non-Google-certified OS. Most banking apps definitely work on GrapheneOS.

We hired 3 experienced app developers a few months ago. That's now our app development team working on overhauling these apps. They've already replaced the entire Messaging app user interface with a new modern Compose UI. Messaging v13 is currently in the Alpha channel and v14 is on the way with a bunch of additional fixes needed for it to reach Beta and Stable. Multiple other apps including Contacts are well into the same overhaul process.

GrapheneOS provides drastically better usability, robustness, overall functional and app compatibility. Privacy and security are also drastically better in AOSP and especially GrapheneOS than that desktop Linux software stack ported to mobile.

All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.

GrapheneOS provides drastically better usability, robustness, overall functional and app compatibility. Privacy and security are also drastically better in AOSP and especially GrapheneOS than that desktop Linux software stack ported to mobile.

All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.

Pixel 3a will lack firmware updates regardless of what you put on it. Having serious unpatched vulnerabilities for radios and other firmware is considered acceptable for desktop operating systems but definitely not by us.

GrapheneOS provides drastically better usability, robustness, overall functional and app compatibility. Privacy and security are also drastically better in AOSP and especially GrapheneOS than that desktop Linux software stack ported to mobile.

All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.

GrapheneOS provides drastically better usability, robustness, overall functional and app compatibility. Privacy and security are also drastically better in AOSP and especially GrapheneOS than that desktop Linux software stack ported to mobile.

All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.

GrapheneOS provides drastically better usability, robustness, overall functional and app compatibility. Privacy and security are also drastically better in AOSP and especially GrapheneOS than that desktop Linux software stack ported to mobile.

All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly high quality open source mobile app ecosystem available there.

GPL is not working for getting us access to what we need. Google often takes weeks or even months to respond to our GPL source requests. Other companies are far worse. What good is it to us if companies can introduce arbitrary delays for months or even years?

There are permissively licensed alternatives to most copyleft projects and they're increasingly the better options. You aren't going to reverse that by licensing niche projects as copyleft. Companies wanting to avoid copyleft can make permissively licensed replacements more easily than ever.

It was shipped in the latest GrapheneOS release. It's currently in the Alpha channel due to reports of carrier compatibility issues for calls which are fixed in today's release. Today's release should be able to reach Beta in a couple hours and then Stable in under 24 hours.

The purpose of GrapheneOS isn't providing a less bad operating system for insecure devices which still lacks anything close to reasonable security patches and protections. It would not be possible to provide the core GrapheneOS feature set on those devices. More importantly, they'd have many years of missing firmware, kernel, driver and HAL updates. Those are among the most important security updates and would not be available in practice. That would not be GrapheneOS and is not the purpose of GrapheneOS.

Android Security Bulletins do list a tiny subset of firmware, Linux kernel, driver and HAL patches so they do require at least very minimal updates to those. Most non-Google-certified operating systems are setting an inaccurate Android security patch level by ignoring the non-AOSP portion of the patches. GrapheneOS doesn't do that but most of the other AOSP-based projects not being certified by Google are doing it. OEMs were caught doing it too but it's not clear if it was intentional in most cases as it is with the alternate operating systems.

Android Security Bulletins set a very low bar since the AOSP patches are available to ship by OEMs 2-6 months prior to the bulletin being published. It's also only High/Critical severity patches being listed. Due to a recent policy change, it's also officially only a subset of the patches for AOSP. That's visible through the Android platform components having patches in the Pixel Update Bulletin for September 2026 despite those being applicable to other operating systems. It's because they no longer want to backport all High and Critical severity patches due to the high volume of issues discovered by AI models. It's similar to how they stopped backporting any Low and Moderate severity patches years ago due to high volume.

Diverting a massive amount of resources to devices where we can never provide decent updates and our core security features doesn't interest us. It would reduce the privacy, security, usability, app compatibility and robustness of GrapheneOS for users on the officially supported devices. It would also result in many people getting insecure devices. Many people would get those devices and then realize they made a poor decision later. We already see this happen with devices approaching end-of-life and already have to put significant work into avoiding people getting those.

Android's official documented listed Pixels as the Android Open Source Project reference devices until the release of Android 16. It also promised 5-7 years of support from launch.

Pixels are sold in 33 countries across North America, Europe, Asia and Oceania. A substantial portion of the Pixel userbase is using other operating systems. 400k to 600k active GrapheneOS users on Pixels is a significant amount based on how many Pixels are sold. It's only one of the alternate operating systems people are using. It's not only a few users as you're claiming.

No, there's a clear commitment to 5-7 years of major OS updates in addition to security updates. Both commitments have been broken for the Pixel 6 through Pixel 9a. Those were sold as Android Open Source Project (AOSP) reference devices but had the updates to it prematurely cut off with Android 16. Pixel 10 and later weren't sold as AOSP reference devices so there was no commitment to providing it, but that's not the case for the earlier devices.

Pixel 9a and earlier were officially sold as Android Open Source Project reference devices. Google made a commitment to providing 7 years of updates from launch for 8th/9th gen Pixels. Google then arbitrarily declared they were no longer AOSP reference devices with the release of Android 16 and stopped providing those updates. Many people bought Pixels due to this and it wasn't fulfilled. GrapheneOS has been able to continue support with a massive amount of work including reverse engineering, but other operating systems haven't been as successful and mostly haven't even moved to Android 17 yet or supported 10th gen Pixels.

There are currently around 400k to 600k active Pixels with GrapheneOS. There have been far more than that when including the past devices our users have purchased. Pixels are a small segment of the overall market and that's substantial. If you add in people on other operating systems such as LineageOS then there are even more people using Pixels with another OS. A significant portion of people who bought Pixels did so because they were AOSP reference devices.

Samsung provides 7 years of support with monthly updates for their flagship devices. Unlike the Pixel OS, Samsung ships a lot of the security preview patches early.

Motorola Signature (2026) has 7 years of support. The upcoming successor to it is the first non-Pixel meeting all of the update and hardware security feature requirements for GrapheneOS.

Pixel 11 currently doesn't meet our security requirements due to at least temporary lack of MTE support which may get added in Android 17 QPR2. The upcoming Motorola device is also going to be using a 6.18 kernel at launch rather than 6.12. We would have launched Pixel 11 series support already if they met our security requirements. It's likely they will down the road but it's not clear why they omitted firmware and software support for a major security feature at launch. It's the firmware part which impacts us.

GrapheneOS will be available on Motorola devices meeting all of our requirements for updates and security features in 2027. It will be starting out on a high end flagship and expanding down from there as devices improve to meet our requirements. We aren't going to support devices unable to provide a reasonable level of security.

Exclusive access to QPR1 and QPR3 releases gives Pixels an unfair advantage over other Android OEMs. They get an extra 2 major updates per year. Introducing new APIs for third party app developers as part of these updates means third party apps will now run best on the Pixel OS. Google apps already run best on the Pixel OS due to many exclusive features. It's Google's standard overall approach to propping up parts of their business with their monopolies in other markets. It's not legal.

Pixels used to have far better updates than any other Android devices but they stopped improving it years ago. It should have kept improving because it's not at all adequate. They need to be able to release OS updates more than once per month and it shouldn't take months for patches to make it into the OS. It currently takes them at least around 2 months to get even the most urgent patches into the OS. They could fix emergency calls being broken if the patch was made around 3 weeks before an OS release, but that's about as quick as they can go. It's not at all adequate for security and is a complete joke compared to Chromium's release cycle. They can get an emergency Chrome update released within a couple days. They should at least be able to do it for the Pixel OS in a week.

GrapheneOS is often around 4 to 6 months ahead on merging Linux kernel LTS releases. We used to handle this ourselves but switched to the Android GKI LTS branch maintained by Greg KH. Unfortunately, it was often struggling to keep up even before the absolutely massive increase in Linux kernel security patches this year. AI models have rapidly accelerated vulnerability discovery and it's an ongoing crisis for the Linux kernel. We want to be on the latest LTS revision within days and want to be using the latest LTS branch within months of it being released. We're not at all happy with how Android is handling things and plan to fix that ourselves. We'll get things back to how they should be.

We also ship all the AOSP userspace patches months before Pixels due to shipping all of the security preview patches as soon as possible. There are sometimes minor regressions but we find and fix them ourselves downstream. The security preview system has a terrible design especially considering that frontier AI models can reverse engineer the patches. There should at least only be a source embargo for around 24 to 72 hours rather than pretending as if it can work with the patches available 2 to 6 months in advance.

QPR1 and QPR3 are now Pixel exclusive since Android 16. That means the new APIs for app developers added in Android 17 QPR1 are Pixel exclusive until Android 17 QPR2. There hasn't been a case of new APIs for apps not being open source or not being available to every OEM since Android Honeycomb (3.x).

It was believed to be an AI generated comment and the issue is already known. We solved it as part of VPN lockdown mode which means it isn't solved for profiles not using a VPN in lockdown mode yet. We could expand our already working approach to always be active but we were concerned about compatibility so we scoped it to VPN lockdown mode.

GrapheneOS does block SO_BINDTODEVICE when VPN lockdown mode is enabled. It doesn't yet block apps in profiles not using a VPN in lockdown mode from using a VPN in another profile due to compatibility concerns but we can likely block it.

We've previously emailed them with no result. This time around we got a reply about this specific account targeting us but it isn't resolved. We don't have much optimism about getting the many past threads with personal attacks based around fabricated stories and harassment content addressed without doing more than asking via email.