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. #GrapheneOS

#GrapheneOS version 2025061300 released. This update backports firmware upgrades from Android 16 to Android 15 QPR2 for security. Android 16 port is being worked on. • 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

Releases | GrapheneOS

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.

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.

We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run #GrapheneOS (

Frequently Asked Questions | GrapheneOS

and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost. In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early. We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release. Due to AOSP no longer having device support, we need to build it ourselves. We can start from the Android 15 QPR2 device support, remove the outdated code and update the configurations. We have tooling to automate generating device support setups which will need major expansions. Since our port to Android 16 is going to be delayed by a week or more, we're in the process of backporting the Android 16 firmware/drivers released on June 10 to the previous releases. This is not something we can do in general so we still need to port to Android 16 this month. Despite our lead developer who has done 90% of the ports for several years being conscripted into an army, we were still able to complete the initial port to Android 16 in under 2 days, but without device support. Our extensive preparation in April and especially May paid off. It's important to get an experimental release out quickly to begin extensive public testing. There are usually many issues found in testing. For a yearly release, we usually get out an experimental release in a day, an Alpha channel release in 2 days and need 4-6 more releases. Google has released a statement claiming AOSP is not being discontinued. This should be taken with a grain of salt, especially considering that they made similar public statements recently followed by discontinuing significant parts of AOSP on June 10.

X (formerly Twitter)

Seang Chau (@seangchau) on X

We're seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an op...

Google is in the process of likely having the company broken up due to losing an antitrust lawsuit from the US government and being in the process of losing several more. There's a high chance of Google losing control of Android in the next couple years.

U.S. Asks Judge to Break Up Google

The Justice Department said the best way to address the company’s monopoly in internet search was to force it to sell Chrome, among other measures.

The leaked information we received in April 2025 indicates that the reasoning they're making substantial cuts to Android is primarily cutting costs, perhaps in anticipation of it being split from Google. The courts should investigate Google's recent changes and cuts to Android.

In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable. Android 16 launched today and porting is going to be significantly more difficult than we were expecting. We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports. Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making #GrapheneOS devices sooner than we expected. We don't understand why these changes were made and it's a major turn in the wrong direction. Google is in the process of losing multiple antitrust cases in the US. Android and Chrome being split into separate companies has been requested by the DOJ. They may be preparing for it. We're hard at work on getting the port to Android 16 done but there's a large amount of additional work we weren't expecting. It can be expected to take longer than our usual ports due to the conscription issue combined with this. It's not good, but we have to deal with it. Having our own devices meeting our hardware requirements (

Frequently Asked Questions | GrapheneOS

would reduce the time pressure to migrate to new releases and could be used to obtain early access ourselves. Based on talks with OEMs, paying for what we need will cost millions of dollars.

GrapheneOS version 2025061000 released.

Releases | GrapheneOS

See the linked release notes for a summary of the improvements over the previous release. #GrapheneOS