grapheneos

OsmAnd has a large legacy C++ codebase with a lot of memory corruption bugs. Many memory corruption bugs have been found and reported by GrapheneOS users. It isn't yet clear if the performance issues the OpenGL renderer has with hardened_malloc are caused by it making too many allocations or actual bugs.

The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.

It's very likely caused by a set of bugs in the app rather than simply inefficient patterns. Users regularly report hardened_malloc detecting memory corruption bugs in OsmAnd.

Those are memory corruption bugs which are potentially exploitable vulnerabilities. There are no false positives for the security protections in hardened_malloc including the hardware memory tagging (MTE) integration. It only detects invalid memory corruptions via use-after-free or out-of-bounds accesses. Due to a relatively high number of apps having invalid memory accesses during regular use, we don't enable MTE for all user installed apps yet. We always use MTE for the kernel and userspace code in the base OS but it's opt-in for most user installed apps via a global toggle to enable it by default and a per-app toggle mainly intended for opting out for incompatible apps.

OsmAnd has a massive amount of legacy C++ code which hasn't been heavily tested with HWASan and MTE. It has a history of having many memory corruption bugs discovered and reported by GrapheneOS users. That's the exploit protections in GrapheneOS working as intended and it's why there are per-app compatibility toggles to work around apps which can't be used due to memory corruption during regular use. It would be better if apps had higher quality native code and didn't need us to provide compatibility toggles but that's the way things are. It's much worse on desktop operating systems.

Google Maps used to work without it but recently gained a hard dependency on Play services. We could add more shims to make more apps work without it installed but that hasn't been a focus yet.

CoMaps and Waze definitely work well on GrapheneOS. There's a known performance issue experienced by some users with the OsmAnd OpenGL renderer which can be worked around disabling hardened_malloc. We could likely provide a performance vs. security toggle for hardened_malloc to avoid it, but we also plan to continue optimizing the default high security mode.

The hardened_malloc configuration in GrapheneOS is the security-focused configuration. OsmAnd ends up acting as a malloc microbenchmark in certain configurations. Users have reported it only happens with the OpenGL rendering mode and it doesn't seem to happen for everyone.

GrapheneOS can provide a performance vs. security toggle for hardened_malloc for these rare cases but it rarely comes up as relevant.

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.