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.

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

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.

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.

Changes in version 137.0.7151.72.0:

• update to Chromium 137.0.7151.72
• disable using in-browser PDF Viewer by default since it's much less secure than our own PDF Viewer, but we plan to add a toggle to enable it in a future release for people who want it regardless

A full list of changes from the previous release (version 137.0.7151.61.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 June security update release based on the June 2025 security patch backports since the yearly Android Open Source Project and stock Pixel OS release scheduled for this month hasn't been published yet.

Tags:

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

• full 2025-06-01 security patch level
• System Updater: temporarily revert notification protection due to upstream Android UI issues for this feature with privileged apps (we still plan to do this but it will need to wait until we resolve the OS issue)
• remove Chunghwa Telecom and Netlock Certificate Authorities (CAs) for fresh installs (will need another change to trigger removal for existing installs) 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)

Tags:

• 2025060100 (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 2025052800 release:

• Media Provider: expand our existing protection against CVE-2024-50089 which is still not addressed upstream (we added generic hardening in 2022 as a prerequisite for Storage Scopes which along with fixing information leaks still unfixed upstream blocked exploiting CVE-2024-50089 for the common cases of not granting permissions, granting media permissions or using our Storage Scopes feature but we didn't fully cover "All files access" or the legacy API level equivalent when not using Storage Scopes)
• System Updater: prevent disabling overall notifications due to lack of a use case and many users doing it by accident, but continue allowing disabling the individual notification channels other than the reboot notification
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.92
• Messaging: update to version 8
• Vanadium: update to version 137.0.7151.61.0

Notable changes in version 8:

• associate contact URIs with notifications to fix starred contacts bypassing Do Not Disturb
• respect "Incoming messages" notification settings when creating notification channels for conversations
• prevent conversation deleted toast spam
• update Guava library to 33.4.8
• update AndroidX RecyclerView library to 1.4.0
• update Android Gradle plugin to 8.10.1
• update Gradle to 8.14.1
• update Kotlin to 2.1.21
• update Android build tools to 36.0.0
• migrate to AndroidX Nullable annotations

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

Changes in version 137.0.7151.61.0:

• update to Chromium 137.0.7151.61

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

Our Contact Scopes and Storage Scopes features provide essential privacy functionality that's missing on standard Android. Scopes are a replacement for the standard contacts, storage and media permissions. We offer these as an alternative when apps request access to any of those.

When you enable Contact Scopes or Storage Scopes, GrapheneOS makes the app believe you've granted the requested permissions. However, it doesn't receive access to any more additional data not created by itself. Most apps work by simply enabling these without doing anything more.

For Contact Scopes, you can choose to give the app read access to a subset of the data for specific contacts. For more convenience, we support grouping contacts together and granting access to a group. It's very useful even without granting access to anything to pretend you have.

Storage Scopes functions differently depending on which permissions are requested. It acts as if the permissions were granted but only allows accessing files created by the app itself and doesn't provide additional info on files created by other apps compared to not enabling it.

Adding scopes after enabling Storage Scopes is only needed to provide access to files created by other apps. For example, if you regularly create files in a directory with both app A and app B and access them with app C, a scope can be granted to app C to access files from there.

Contact Scopes and Storage Scopes work around the fact that most app developers do not use the system contact picker, file picker, etc. but rather request broad access via permissions. We're going to be adding more similar features providing an alternative for more permissions.

Following our port to Android 16, providing similar features for Camera, Microphone and Location will be among our top priorities.

For Location, it will allow setting a per-app location instead of granting the permission. Android has Mock Location already, but it's a global.

For Camera, you'll be able to set a picture or video file to loop for the app as an alternative to granting the permission. For Microphone, you'll be able to set an audio file to loop for the app.

We plan to expand this approach to other permissions further in the future too.

We recommend not granting storage or media permissions to user installed apps. Storage Scopes should be a full substitute for those already.

Contact Scopes is not quite a full substitute yet since it can't permit write access or shared accounts, but we plan to expand it later.

Storage Scopes can even be used as a full replacement for Android's file manager permission ("All files access") giving access to the entire home directory. Android acknowledges that is dangerous and tried to restrict access to a couple special use directories but nothing else.

Android's only restrictions on apps granted file management access are not allowing access to Android/data and Android/obb. Android/data is an alternative to internal app storage where users get file access. Android/obb is a long time deprecated way to distribute large files.

Due to an upstream Linux kernel vulnerability, Android's attempt at restricting access to Android/data and Android/obb for the file management permission didn't work (https://nvd.nist.gov/vuln/detail/CVE-2024-50089). A fix was implemented in the Linux kernel, then reverted due to breaking compatibility.

Fix:

https://github.com/torvalds/linux/commit/5c26d2f1d3f5e4be3e196526bead29ecb139cf91

Revert:

https://github.com/torvalds/linux/commit/231825b2e1ff6ba799c5eaf396d3ab2354e37c6b

CVE assigned to this (CVE-2024-50089) was then rejected, since the Linux kernel project took over managing Linux kernel CVEs and only allows CVEs for their backported patches, not as a vulnerability tracking system.

Fixing this outside the kernel is problematic. Most approaches will end up having bypasses. Android has struggled to do that and seems unwilling to temporarily apply a kernel patch. Some other AOSP-based projects are adopting an approach to this we don't believe is correct.

Android 16 appears to have an attempt at a full fix in userspace. "All files access" grants will still be dangerous and privacy invasive.

Storage Scopes is our way of making the best out of maintaining compatibility with a messy coarse permission model with odd special cases.

In Android 4.4, support was added for apps using the system file picker to have users choose files for them. In Android 5, it was extended to directories. Adoption of this was extremely poor until they began coercing apps to use it. There's now also forced photo picker support.

Our Storage Scopes feature is not a restriction but rather a better alternative to granting storage and media permissions. It's better if apps support the system file picker. Apps prefer demanding bulk data access over that. On GrapheneOS, you can say no and still use the apps.

Our Storage Scopes feature includes additional hardening which caused the serious Linux kernel CVE-2024-50089 vulnerability to be much less severe with GrapheneOS due to mostly limited the impact to the "All files access" permission rather than cases without that being granted.

Tags:

• 2025052800 (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 2025052000 release:

• disable anti-competitive code being injected by the Play Store into apps choosing to enable "App integrity > Automatic protection" when there's a valid Play Store source stamp signature (proving that it's an unmodified app from the Play Store, so we aren't disabling an integrity check) since it prevents using the apps on GrapheneOS when apps also choose to enable "App integrity > Store listing visibility" with either the "Device integrity checks" or "Strong integrity checks" values enforcing having a device licensing Google Mobile Services and running the stock OS (circumventing this is protected by the DMCA exemption for jailbreaking)
• Private Space: fix further issues with quiet/locking state changes in secondary users
• extend NFC auto-turn-off to work when logged into a secondary user
• kernel (6.6): update to latest GKI LTS branch revision
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.140
• Vanadium: update to version 137.0.7151.44.0
• Vanadium: update to version 137.0.7151.44.1

Changes in version 137.0.7151.44.1:

• fix upstream picture-in-picture regression in Chromium 137

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

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.

In order to provide better support for blind users, we maintain a fork of the open source TalkBack app fixing serious issues with it, modernizing it and making the builds reproducible. One of the goals of making our own Setup Wizard has also been integrating TalkBack support.

Google unfortunately doesn't publish the source code for each stable release of TalkBack as they do for Android itself. The open source release of the app lags significantly behind. It also has a bunch of missing and broken features. We plan to gradually improve this situation.

In order to use GrapheneOS, blind users need to successfully install the OS and set up the device to be usable with a screen reader. This is an area we've been thinking about and working on improving for a while. Our new Setup Wizard provides a better base for integrating this.

The first barrier to someone using GrapheneOS without sight is installing the OS. We've done what we can to make our web installer as accessible as possible (https://grapheneos.org/install/web). However, users need to interact with the device's firmware interface which the user can see.

Due to the inaccessible firmware user interface, it's difficult to perform the installation correctly and safety, particularly confirming unlocking and then confirming locking. Confirming the verified boot key matches after installing/locking would require OCR on another device.

The next issue is the Android Open Source Project no longer includes a text-to-speech app. Pico TTS used to be included in AOSP but was not what Google Mobile Services devices use. It was quite primitive, awful to use and AOSP removed it after security issues were found.

We've wanted to include a text-to-speech app and bundle a language pack to have it working out-of-the-box for a long time. We could then add a shortcut for enabling TalkBack in our new Setup Wizard to make things accessible from the start of the post-install setup process.

To provide what we need, the TTS app needs to be built into the OS, enabled and set up to work by default without configuration. It doesn't do any good if you need to connect to a network and download a language pack. It also needs to work Before First Unlock via Direct Boot.

Since it will be enabled by default, security is quite relevant. It shouldn't be a bunch of C++ code without a modern coding style, use of sanitizers, decent tests, etc. It needs to be actively developed and properly maintained. This is why Pico TTS had to be removed from AOSP.

GrapheneOS is intended to be a drop-in replacement for the Android Open Source Project usable by companies to make all kinds of products. Due to this, we avoid non-commercial usage licenses. Lots of the language packs for TTS implementations have non-commercial usage licenses.

We also avoid including GPLv3 code in the base OS since it would add restrictions on how it can be used. We do add new GPLv2 licensed code. This doesn't mean we have issues with using GPLv3 code or making forks of GPLv3 projects, we just don't bundle it within GrapheneOS itself.

Neither eSpeak NG or RHVoice meets our security expectations (piles of problematic C and C++ code) and both have licensing issues. Both were previously also missing Direct Boot support to function Before First Unlock, but we requested it from both and eSpeak NG implemented it.

There were previously no good options available. Things have changed and there are multiple open source text-to-speech implementations which could be turned into a suitable Android app and integrated into the OS. This involves significant work and we haven't gotten to this yet.

We have hundreds of planned features. We've been working on some features for months or even years. We try to focus on features which would provide the most overall benefit to our users with a focus on improving privacy, security, compatibility and usability. It's subjective.

For example, built-in support for network location was a feature we wanted to integrate for years. Last year, we made it a top priority, and assigned a developer to solely work on it, so it got done. This is still being worked on to add cellular fallback and full offline support.

Changes in version 137.0.7151.44.0:

• update to Chromium 137.0.7151.44

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

A growing number of apps are using the Play Integrity API to enforce installation from the Play Store. This is clearly highly illegal anti-competitive behavior. It doesn't impact GrapheneOS users installing apps with the sandboxed Play Store but does impact other install sources.

This is being done alongside Google recommending app developers forbid installing their apps from the Play Store on operating systems not licensing Google Mobile Services. The combination of these feature ends up blocking users from easily using the apps without modifying them.

We're going to add a secure way of working around this without breaking the app source security model. We'll be adding support for having the OS automatically verify the Play Store signing metadata and then inform Play services those apps were installed from the Play Store.

It's worth noting Android has a standard hardware attestation API for verifying the hardware, firmware, OS and app. This supports alternate roots of trust and non-stock operating systems if apps choose to support it. Apps could perform stronger checks while allowing GrapheneOS.

Android's hardware attestation API has anti-competition issues due to the official verification libraries hard-wiring the Google roots and encouraging only permitting the stock OS. However, it does fully support any other OS with verified boot and can be used with other root CAs.

Google's Play Integrity API is quite different and only supports verifying devices licensing Google Mobile Devices with the stock OS. It has support for enforcing installing apps from the Play Store. None of this has anything to do with security. It's purely anti-competitive.

Google Play Integrity permits highly insecure devices with years of missing High/Critical severity security patches. They pretend any device licensing Google Mobile Services is secure while running the stock OS and anything else is insecure. This is a lie to lock out competition.

There's no security value to enforcing using devices licensing Google Mobile Services. The vast majority of those devices are highly insecure. Software-based attestation (device integrity) is also highly insecure and easy for attackers to bypass. This is only hurting competition.

Hardware-based attestation can be secure, but the way the Play Integrity API uses it is also highly insecure. It can be bypassed via leaked keys from the most insecure Android devices in the ecosystem. Secure way to use it is pinning, not trusting everything chaining to a root.

Even if apps insist on doing these kinds of integrity checks, they can still permit GrapheneOS. We provide a guide on verifying GrapheneOS via hardware attestation at https://grapheneos.org/articles/attestation-compatibility-guide. They can still fall back to Play Integrity API for insecure devices without this.

Multiple prominent banking apps in Europe have already implemented support for GrapheneOS via hardware attestation. The pace of apps adopting the Play Integrity API is unfortunately currently faster than apps adding support for GrapheneOS. This is due to Google marketing it.

If you run into apps banning using GrapheneOS with Play Integrity, make a Play Store review with no links asking to stop banning a more secure OS. Next, make a customer support request linking https://grapheneos.org/articles/attestation-compatibility-guide. Multiple apps have permitted GrapheneOS due to these efforts.

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.