KindnessInfinity

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.

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