KindnessInfinity

Android 15 is being released today and we should be ready to quickly ship a release based on it as if this is a monthly update, not even a quarterly one.

We already put together builds working well across all supported devices based on the Android 15 Beta and September sources.

Source code tags are currently in the process of being pushed to the Android Open Source Project repositories. In a few hours, those should be fully pushed and we can build official releases of GrapheneOS based on Android 15. We'll push it out via Alpha quite quickly for testing.

We shipped October Android Security Bulletin patches significantly before stock Pixel OS:

https://grapheneos.org/releases#2024100800

Android 15 is required for full Android security patches now. Android Security Bulletin only covers a subset of the patches they deem important enough to backport.

In addition to Android 15 being required for the full set of Android Open Source Project patches, it's also now needed for even the basic set of hardware-related patches for Pixels since they're on Android 15. Pixel Update Bulletin was published today:

https://source.android.com/docs/security/bulletin/pixel/2024-10-01

We've been working hard on preparing for the release of Android 15 and it should be the smoothest yearly release we've had so far largely due to them providing an early source code release in September. That was unusual and we won't plan around it being repeated for Android 16.

We built an initial experimental release based on Android 15 (2024101500) which worked well but we were missing some of the intended kernel changes. We've thrown that out and we're building a new release (2024101600) which should be the first one able to reach the Alpha channel.

We've been testing our port since September 3rd using Android 15 source code published in September. We were testing builds for Pixels prior to today's release via Beta releases. We planned to do public testing of experimental builds but people would have needed a spare device...

This yearly Android release happened a lot differently than previous years: trunk-based quarterly releases since QPR2 making it much smaller and allowing earlier testing even before September, and then the early source code release not actually shipped in production to devices.

Overall, both of these things eliminated most time pressure and stress for us. However, we had to keep developing our Android 14 QPR3 stable branch despite having a 99.9% complete port to Android 15 since September 3rd and they didn't quite publish enough for public testing.

Changes in version 141:

• update max supported version of Play services to 24.41
• update max supported version of Play Store to 43.1
• update Android Gradle plugin to 8.7.1

A full list of changes from the previous release (version 140) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Changes in version 13:

• add support for ARM hardware memory tagging (MTE) which has been shipped in production on GrapheneOS for the past year (see the README section on memory tagging for details)
• Android: implement fatal_error() via async_safe_fatal() for improved logging
• Android: restore the default SIGABRT handler in fatal_error() before aborting to avoid deadlocks with crashlytics
• Android: remove redundant warning switches for Android
• fix -Wimplicit-function-declaration warning with GCC 14
• update libdivide to 5.1

A full list of changes from the previous release (version 12) is available through the Git commit log between the releases.

See the README for this release for an overview of the project and many details about the design goals and implementation.

This is a standalone release for use outside of GrapheneOS. GrapheneOS ships these changes shortly after they're implemented as part of our OS releases rather than waiting for these releases.

These integer tags are the standalone releases, while date style tags such as 2024101200 and 2024101200-caimito are part of GrapheneOS releases and may contain GrapheneOS-specific changes such as workarounds for latent memory corruption bugs encountered in the wild while waiting for an upstream or downstream fix.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024101200-redfin (Pixel 4a (5G), Pixel 5)
• 2024101200 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, emulator, generic, other targets)
• 2024101200-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024100800 release:

• hardened_malloc: preserve hardware memory tagging enforcement flag for slab mappings when releasing free slabs
• hardened_malloc: improve accuracy of probability hint for hardware memory tagging branches
• temporarily revert enforcing minimum 64kiB stack guard size for arm64 since Facebook recently included a buggy stack overflow check for the React Native Hermes runtime that's incompatible with larger gap sizes and beginning to be shipped by apps
• Log Viewer: add "bootloader unlocked" and "dev options enabled" flags to header
• Log Viewer: add "More info" button to native crash reports
• Log Viewer: include contents of App Not Responding (ANR) stack traces file in ANR error reports
• Log Viewer: omit processUptime header line when it's unknown
• Settings Intelligence (Settings search): fix upstream bug resulting in corruption of the query history database which leads to the search crashing
• Launcher: mark 2x2 workspace option as being for phones
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.54
• adevtool: update out-of-band carrier settings
• Vanadium: update to version 129.0.6668.100.0

We've improved the layout of the list of releases on our site and added the Alpha channel to the list. The overall changes should make it more useful and easier to understand:

https://grapheneos.org/releases#devices

Each official release of GrapheneOS goes through Alpha and Beta before Stable.

Facebook shipped buggy stack overflow detection in the Hermes JavaScript engine used by React Native:

https://github.com/facebook/hermes/issues/1535

It breaks when the default stack guard is 64k instead of 4k. The standard 64-bit ARM Linux ABI requires 64k. So far only 1 person noticed a broken app.

We're going to be temporarily reverting our change in today's release before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.

Not particularly important since we weren't planning on switching to standard 64k stack probes instead of 4k stack probes to avoid risk. However, it's nicer if it's larger to cover 3rd party code without stack probes. Very minor compared to other things blocked by app compat.

The main feature that's blocked due to third party app bugs is enabling hardware memory tagging by default for all user installed apps. That works fine but catches many memory corruption bugs. We might put the toggle into the setup wizard so that most users end up enabling it.

We want to disable the 32-bit ARM system call ABI in the kernel config on devices without 32-bit app support. Certain widespread anti-tampering frameworks use it even on devices like the Pixel 8 without CPU level support for 32-bit. We'll have to extend the seccomp filters.

Enabling ShadowCallStack for Vanadium worked well but caused issues with WebView-based apps, likely due to anti-tampering code. This would be nice even on the recent devices with PAC and MTE until we have stack allocation MTE enabled... which is blocked due to app bugs for now.

There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific.

Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.

It goes through connections for the Google Play network-based location that's offering as an option during the initial setup wizard, the optional Google Play account-based device management, Google Play feature flags, Google Play telemetry, etc. It gets a lot of details wrong.

iOS has direct equivalents to everything that's covered.

If what people take from the article is that they should use a non-Pixel Android device with Google Play, they'll have a dramatically less secure device with the same privacy issues and additional ones from OEM services.

If what people take from the article is they should use an iPhone instead of a Pixel, they'll have a device with comparable security and similar privacy invasive default connections. iOS does provide better privacy from third party apps than AOSP or the stock Pixel OS, at least.

Unfortunately, the article contributes to people using typical highly insecure Android devices with additional privacy invasive connections, not fewer. If it was promoting iOS over Android, at least it would be helpful overall despite being highly inaccurate. Tech news is awful.

People are having their privacy and security harmed by journalists misleading them because most journalists don't do basic due diligence and simply repeat claims from elsewhere without verification. Many people in the privacy and security communities are doing the same thing.

GrapheneOS is a major security upgrade over the stock Pixel OS or iPhone, but it doesn't mean we're on board with spreading misinformation about either of those. They're the most secure smartphone options and iOS is a clear next best overall choice for privacy after GrapheneOS.

iOS has important privacy features missing in standard Android. Our Storage Scopes feature is needed for parity with iOS. Our Contact Scopes is better than what they added in iOS 18 but it's similar. iOS having better privacy FROM APPS than Android definitely does check out.

The idea that iPhones have better privacy from Apple than Pixels do from Google is largely just a misconception and there's a whole lot of confirmation bias happening. Apple does have better end-to-end encryption support which most users aren't actually enabling for iCloud, etc.

There are a lot of alternative operating systems and supposedly private/secure phone products. Nearly all of these have dramatically worse security than the stock Pixel OS or an iPhone. Nearly all have worse privacy from apps than iOS. They have their own problematic connections.

In terms of privacy from apps, GrapheneOS is competitive with iOS with both advantages and disadvantages. In terms of overall privacy, GrapheneOS is a significant upgrade. Security is a much clearer win for GrapheneOS since Pixels are quite competitive without our work anyway.

Android has useful privacy features unavailable in iOS such as user profiles, Private Space in Android 15, better VPN support, etc. GrapheneOS adds more advantages, and we address the weakness of privacy from apps but not yet to the point it's a clear upgrade in that one area.

Changes in version 129.0.6668.100.0:

• update to Chromium 129.0.6668.100

A full list of changes from the previous release (version 129.0.6668.81.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

This is an early October security update release based on the October 2024 security patch backports since a monthly Android Open Source Project and stock Pixel OS release based on Android 14 QPR3 hasn't been published yet. Android 15 is scheduled for release around October 15th and they may not have a monthly release based on Android 14 QPR3 before then.

Pixel 4a (5G), Pixel 5 and Pixel 5a are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024100800-redfin (Pixel 4a (5G), Pixel 5)
• 2024100800 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, emulator, generic, other targets)
• 2024100800-caimito (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold)

Changes since the 2024092900 release:

• full 2024-10-01 security patch level
• overhaul the implementation of our USB-C port control feature to improve robustness and error reporting
• fix an upstream Android Bluetooth use-after-free bug uncovered by GrapheneOS hardware memory tagging that's triggered when obtaining internet access from another device via Bluetooth
• fix an upstream Android race condition bug in handling of system error files to avoid using the wrong timestamps for system errors and then reporting them as new errors after reboot
• work around an upstream Android bug causing our Log Viewer feature to stop working after system_server restarts
• add handling for early boot-time system journal notifications
• kernel (5.10, 5.15, 6.1, 6.6): backport upstream patch fixing a hole in SELinux W^X enforcement
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.226
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.167
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.112
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.53
• TalkBack (screen reader): update dependencies
• Vanadium: update to version 129.0.6668.81.0
• GmsCompatConfig: update to version 140

Our understanding is that there will be a stable release of Android 15 on October 15th. We fully ported all our changes to it by September 3rd after the early source code release in September. We'll aim to have a release out within 24h of the stable release being pushed to AOSP.

Today, they published the Android Security Bulletin for October with the security patch backports to the initial releases of Android 12, 12L, 13 and 14. There should be a monthly release based on Android 14 QPR3 today or tomorrow. If not, we'll do a release with the backports.

We've started preparing a release based on the backports in case we need it. One of the patches has major conflicts since these are meant for the initial Android 14 not Android 14 QPR3. It's unfortunate we have to waste resources because they won't share this information with us.

Recent examples where we could have waited if we knew the release date in advance:

August early ASB release: https://grapheneos.org/releases#2024080500

August monthly release: https://grapheneos.org/releases#2024080600

July early ASB release: https://grapheneos.org/releases#2024070200

July monthly release: https://grapheneos.org/releases#2024070201

For months with quarterly and yearly releases, it's common for our early ASB release approach to get those patches to our users days or even weeks early. However, the recent months where they released on Tuesday instead of Monday wasted our time without getting much from it.

Fixing conflicts for the backports can take a lot of time and often requires very skilled work to do it properly as it will for one of the patches this month. Doing an extra OS release also takes a lot of our resources. It takes a lot of local compute time and testing effort.

This shouldn't be something we need to spend resources on because we should know the official release schedule and should have early access. It's harming Android more than GrapheneOS since these kinds of artificial issues inflicted on us are exactly why we stopped contributing.

Changes in version 140:

• update max supported version of Play services to 24.40
• update max supported version of Play Store to 43.0

A full list of changes from the previous release (version 139) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Changes in version 129.0.6668.81.0:

• update to Chromium 129.0.6668.81

A full list of changes from the previous release (version 129.0.6668.70.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.