KindnessInfinity

Tags:

• 2025061900 (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, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025061600 release:

• full 2025-06-05 Pixel security patch level based on Android 16 backports (full Android 2025-06-05 patch level was provided in an earlier release)
• Pixels: backport Android 16 Wi-Fi firmware, Bluetooth firmware and TPU firmware
• Pixels: backport Android 16 Samsung Radio Interface Layer (RIL) code
• Sandboxed Google Play compatibility layer: fix rare system_server crash reported with Android Auto by adding check for a null calling package
• Vanadium: update to version 137.0.7151.115.0

We previously shipped our builds of Android 16 kernel drivers along with the new Pixel SoC firmware and cellular radio firmware. Today, we'll be making a release with the new Wi-Fi/Bluetooth firmware, TPU firmware and RIL code. This will provide the Pixel 2025-06-05 patch level.

We want to backport a few more things such as the userspace Mali driver library to make sure we have all the important patches.

Our initial Android 16 port was finished days ago and we've made a lot of progress towards replacing the device support which was dropped from AOSP 16.

Pixel patch levels include more than the baseline Android patch levels and we intend to include all of that before claiming to have the latest patch level. It's not supposed to only mean the Android Security Bulletin patches but rather ASB + a bulletin from the device vendor.

June 2025 Android Security Bulletin was released June 2nd and our 2025060200 release incorporated those Android Open Source Project patches. Pixel stock OS released those and additional Pixel firmware/driver patches for the month on June 10th as part of the Android 16 release.

We ported to the new major OS release quickly and would have had an experimental release out on June 12th if AOSP 16 hadn't made things harder. Backporting the driver/firmware patches is problematic so we don't usually try but rather get the new release out very quickly instead.

In hindsight, it would have made sense to focus on the backports first since the port is taking much longer than planned. It'll be done this month and that's crucial to continue providing further security patches for July onwards along with security improvements beyond bug fixes.

Changes in version 137.0.7151.115.0:

• update to Chromium 137.0.7151.115
• disable Local Network Checks for WebView since apps may not be compatible with it, with one example being the captive portal handling app built into the OS which is only partially compatible (this was previously shipped as part of Vanadium Config version 101 by changing the feature flag for the WebView)

A full list of changes from the previous release (version 137.0.7151.89.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.

Tags:

• 2025061600 (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, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025061500 release:

• update to Android 16 kernel drivers and build system to ship the Pixel kernel driver patches from Android 16 while we're still reimplementing device support for Pixels due to AOSP removing it

Tags:

• 2025061500 (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, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025061300 release:

• adjust our hard-wired Android 16 cellular radio version string to pass the case sensitive check done by the install process
• adjust the SUPL disabled mode to work around Samsung gnssd (Pixel 8a and all 9th gen Pixels) not implementing SUPL_MODE properly (reboot is required for the Off mode to kick in on these devices)
• Messaging: update to version 11

We need to do a large number of generate-prep and development builds as part of finishing up our new approach and automation for Pixel device support. Can anyone get us cloud computing credits? Otherwise, we need to start paying for multiple new Hetzner dedicated servers.

We do all production builds on 3 local GrapheneOS Foundation machines and each OS developer has at least one powerful local workstation. However, we need a lot more computing power than usual due to the way we're adding back device support to AOSP requiring many clean builds.

Notable changes in version 11:

• temporarily revert AndroidX fragment/loader/preference library migration due to what appears to be an upstream Messaging or AndroidX bug causing the app to go back to the conversation list when returning to it

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

Notable changes in version 10:

• revert change to process message data in secondary users since it caused a regression (duplicate received messages from secondary users) and needs to be done another way

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

Notable changes in version 9:

• process message data in secondary users
• avoid creating conversation channels prior to users configuring notifications for them
• mark bubbled conversations as read
• remove duplicate observable conversation sound
• migrate to AndroidX Fragment, Loader and Preference libraries
• update AndroidX Appcompat library to 1.7.1
• update Gradle to 8.14.2

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

Tags:

• 2025061300 (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, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2025061000 release:

• update SoC and cellular radio firmware to the Android 16 releases to ship the security patches prior to our Android 16 port
• Vanadium: update to version 137.0.7151.89.0
• Messaging: update to version 10

We'll be making at least one more Android 15 QPR2 release soon to ship backports of important firmware and driver security patches released with Android 16. This wouldn't usually be required since we'd have Android 16 released to end users using the Alpha channel and soon Beta.

We've ported all of our features to Android 16. However, part of our hardware-based USB-C and pogo pins port control feature may need to be reimplemented due to being part of device support code. We have a lot of work remaining reimplementing device support removed by AOSP 16.

We have early builds based on Android 16 booting on Pixels but will need to do a lot more work to reach production quality.

We're also beginning building/testing backports of Android 16 firmware updates to Android 15 QPR2 with the aim of releasing those patches to Alpha today.

Our initial port to Android 16 has been completed and can be built for the emulator from our 16 branch. All of the device-independent GrapheneOS code has been ported. There are some parts of the port which will be redone better and a lot of testing and fixing regressions to do.

Normally, we would have announced the availability experimental releases based on Android 16 already. Unfortunately, Android 16 dropped device/hardware support from the Android Open Source Project and we're going to need to put it together ourselves without being prepared for it.

We'll be starting from the Android 15 QPR2 device support code and stripping it down to a bare minimum. Pixel 9a is a special case and will be more work.

Our hardware-based USB-C port control feature will no longer work with this approach and we need to replace half of the code.

We received early notice of Android 16 removing the device support code from AOSP but were unable to confirm it or determine the details. We have existing automated tooling for this we can significantly extend to generate what we need. It will be difficult and a major regression.

Paying an ODM to make a Snapdragon device for us is increasingly appealing. We would have all the device support code we need, could build it with compiler-based hardening and would be able to harden a lot of the device's firmware. We could also make secure element applets.

We want to be building privacy and security features. We don't want to be wasting our efforts on adding device support and other basic functionality to AOSP. It appears the only way we're going to be able to do that is paying millions of dollars to an ODM to have a proper base.

As an example of what we would be able to do even with an entirely standard reference device, we could add hardware support for our duress PIN/password feature to the secure element so that successfully exploiting the OS could not bypass it. We could do a whole lot with firmware.

Pixels meeting our requirements is why many of them were and are being purchased. We've reported MANY vulnerabilities over the years which have been fixed for Android and Pixels. We've proposed hardware, firmware and many software level security enhancements they've adopted.

We would prefer not having to pay millions of dollars to have a phone produced for us. It's entirely doable but we would need to repeat it every few years. We'd rather work with an OEM with aligned goals and willing to provide first class GrapheneOS support to sell more devices.

Pixels have substantially benefited from meeting our requirements and having GrapheneOS available for them. We know there's a significant market for an OEM working with us to make a more secure device with hardware-based security features not available on Pixels or iPhones.