KindnessInfinity

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 (https://grapheneos.org/faq#future-devices) 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.

https://x.com/seangchau/status/1933029688202703062

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.

https://www.nytimes.com/2025/04/21/technology/google-search-remedies-hearing.html

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.

Google has been accelerating their crackdown on alternate mobile hardware and software with the Play Integrity API combined with laying off many people working on Android and cutting parts of the project. They disallow their OEM partners from competing so others cannot take over.

It's no wonder that Android and Chrome engineers at Google are leaking tons of information when the company is in an extraction mode trying to get as much out of each as possible prior to Google being broken up. Regulatory action needs to move faster and take this into account.

A successful mobile OS will need near perfect iOS or Android app compatibility. For Android, compatibility means a solid fork of AOSP even if it's only used within a VM on a more modern microkernel-based OS. Google made an open platform, unlike Apple, and could not prevent this.

For years, Google has been using extraordinarily anti-competitive Google Mobile Services (GMS) licensing agreements with OEMs to disallow competition. To further prevent competition, they made the Play Integrity API where apps devs are convinced to check for valid GMS licensing.

If the Pixel 10 does meet our requirements, we'll support it, but it will take significantly more time and effort to develop support for it. At the end of the year, Qualcomm should finally release a new SoC providing hardware memory tagging. If they do, we can shift focus to it.

Once an OEM offering the service of making custom devices has a platform based on a new Qualcomm Snapdragon SoC with hardware memory tagging support, we can do a crowdfunding campaign to raise the money needed to have them build a device for us. We have talked with a couple OEMs.

The baseline will be several million dollars, which can be spread out across the cost of preordered devices. This is the cost of making a modern, secure device with a secure element and the other requirements we have for one instead of a low-end device with outdated hardware.

There will be a cost of a million or more dollars per year of additional support. Providing 7 years of proper support like Pixels would be very expensive. We definitely wouldn't be releasing a new device every year as the overlapping costs for all of it would be ridiculous.

Changes in version 137.0.7151.89.0:

• update to Chromium 137.0.7151.89
• drop backport of Picture In Picture (PiP) patch now present upstream

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

In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable (https://grapheneos.social/@GrapheneOS/114359660453627718). 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 (https://grapheneos.org/faq#future-devices) 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.

We've made a lot of progress on porting to Android 16 already. If things hadn't been made harder for us, we would likely be able to publish an experimental release tomorrow and quickly get a release into the Alpha and then Beta channels to start ironing out the bugs in the port.

Our speculation about this is that a result of Google losing a US antitrust case and likely losing several more soon, they're preparing for Android and Chrome being split into separate companies. If Android gets split off, they want to retain Pixels.

https://www.nytimes.com/2025/04/21/technology/google-search-remedies-hearing.html

Google seems to be in the process of splitting up Android and Pixels along with moving towards treating other Android-based platforms as their competitors instead of their partners. Pixels retain first class alternate OS support with Android 16 firmware so it's not about that.

We have early builds of GrapheneOS based on Android 16 booting in the emulator. We would usually be working on quickly porting over device support and getting the kernels ready including doing the production kernel builds now. Unfortunately, that will be harder than usual.

This will likely be the final release based on Android 15 QPR2 since Android 16 has been released today.

Tags:

• 2025061000 (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 2025060200 release:

• expand our code for checking Google Play Store source stamp signatures to checking each split APK in order to prepare it for future security-relevant usage including optionally marking apps as installed from the Play Store after verifying the source stamp (this is currently used for stripping Play Store inserted checks for apps being installed from the Play Store which had looser security requirements)
• remove Chunghwa Telecom and Netlock Certificate Authorities (CAs) based on the decision by the Chrome Root Store (this does not impact Vanadium since it uses a more sophisticated browser root store rather than the OS root store and will distrust certificates from these CAs not added to Certificate Transparency logs before 2025-08-01 to avoid website compatibility issues)
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.141
• kernel (6.6): update to latest GKI LTS branch revision
• Vanadium: update to version 137.0.7151.72.0
• Vanadium: update to version 137.0.7151.72.1
• Network Location: increase difficulty of position estimation tests to help avoid regressions

Changes in version 137.0.7151.72.2:

• disable permission prompt for Local Network Access until it's supported on Android to avoid rare crashes impacting some users
• backport upstream patches for the Local Network Access checks feature we're enabling early
• replace our patch for an upstream Picture in Picture (PIP) bug with a backport of an upstream patch

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

Changes in version 137.0.7151.72.1:

• enable Local Network Access checks by default (this was already shipped in Vanadium Config 95 so it doesn't change anything for users with up-to-date Vanadium Config)
• add chrome://flags toggle for Android for the Local Network Access flag we're enabling by default so users can disable it (will be replaced by a site setting UI in the future)
• drop change for testing Android 16 support prior to Android 16 release to prepare for the upcoming Android 16 stable release

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

WebRTC is a peer-to-peer communications protocol for web sites and therefore causes numerous privacy issues through making direct connections between participants. By default our Vanadium browser disables the peer-to-peer aspect by only using server-based (proxied) connections.

Vanadium provides a user-facing setting at Privacy and security > WebRTC IP handling policy.

From least to most strict:

DefaultDefault public and private interfacesDefault public interface onlyDisable non-proxied UDP

For Vanadium, "Disabled non-proxied UDP" is the default.

The tracking technique described at https://arstechnica.com/security/2025/06/meta-and-yandex-are-de-anonymizing-android-users-web-browsing-identifiers/ is prevented by Vanadium's default "Disabled non-proxied UDP" value. It's also prevented by "Default public interface only", which does permit peer-to-peer connections but won't try to use the loopback interface for it.

We have a list of most of the features provided by Vanadium at https://grapheneos.org/features#vanadium. There are dozens of additional privacy and security features planned along with data import/export and improved support for system backups. It takes time to implement these things properly.

Vanadium doesn't have billions or even millions of users which limits our ability to prevent fingerprinting. We plan to address this by launching it for use outside GrapheneOS including publishing it through the Play Store. We want to implement more of the planned features first.

For the non-WebRTC issue being abused by Yandex, Chromium 137 shipped a fix for it behind a feature flag that's being gradually rolled out. We can roll this out to 100% of Vanadium users through a Vanadium Config update. We can start Alpha testing for that new flag later today.

Vanadium Config version 95 enables protection for local networks and loopback. The user interface for making per-site exceptions isn't available for Android yet. The overall feature can be disabled via chrome://flags if for some reason someone needs that functionality right now.

We're looking into using https://github.com/k2-fsa/sherpa-onnx to provide built-in text-to-speech and speech-to-text to greatly improve the out-of-the-box accessibility of GrapheneOS for blind users. We already have a screen reader included via our fork of the open source variant of TalkBack.

To have text-to-speech functioning out-of-the-box, we can choose one of the models with open source training code and data as the default to be included within the OS. We wouldn't need to include anything that's not truly open source. It's the only reasonable option we've found.

There are over 100 models for 40 languages. Some research is going to be required to figure out which of the English ones are fully open source (open training data and code) and then which of those works best for basic text-to-speech to have as the default bundled in the OS.

If we had text-to-speech support included in GrapheneOS, we could also provide an automatic captions feature.

We'll need to do a basic review of the code for text-to-speech, speech-to-text, shared code and any other parts we decide to use. We'll need at least a minor fork of it.

We want to stick to a model with open source training code/data for what we bundle, so we're likely not going to be able to use one of the best options by default. Having a tolerable open source model by default with the option to switch to great "open" models seems good enough.

We could use help narrowing down which of the available English models with open training data would be best (least bad) for basic text-to-speech usage including for TalkBack. We could also collect feedback somewhere on which ones people think are best overall across languages.

We still need help getting early access to Android 16 sources prior to the stable release in June. Every mainstream Android OEM has it. We're currently spending significant time on reverse engineering Android 16 Beta releases. It's a huge waste compared to having what we need.