GrapheneOS [Unofficial]

Tags:

• 2025042500 (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 2025041100 release:

• Bluetooth: backport upstream fixes for compatibility with certain Bluetooth peripherals caused by a recent security fix for Bluetooth encryption
• avoid granting special runtime permissions (Network, Sensors) added by GrapheneOS when unarchiving an app
• use our restricted setting infrastructure to restrict system app access to our notification forwarding setting too
• Settings: prevent disabling system Dialer app since it's always required for emergency calls
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.134
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.87
• Vanadium: update to version 135.0.7049.100.0
• Vanadium: update to version 135.0.7049.111.0
• Vanadium: update to version 136.0.7103.44.0

ReliableSite has provided two sponsored servers to replace our North American update servers. One is in Los Angeles and the other In Miami. Each has a 9900X, 196GB RAM, 2x 4TB NVMe and 10Gbps bandwidth. We greatly appreciate the support.

https://www.reliablesite.net/

We've already set up both servers, tested them and deployed them to production by adding them to our GeoDNS configuration:

https://github.com/GrapheneOS/ns1.grapheneos.org/compare/d78f0f087446789628927f36bb66268d4bc9cb16...d09a8917742e0c262344ccecfca46b6bb15e1ff1

This was based on our split between Las Vegas and Beauharnois (Quebec) for our website and network servers and may be adjusted.

We were previously provided with a 25Gbps server in Amsterdam by Macarne. These 3 servers now handle all of the traffic for OS and app updates along with fresh installs. It would help to have servers from providers with great peering in a few more places.

https://grapheneos.social/@GrapheneOS/114264453740567840

We should have enough bandwidth for at least the next year or two now. It would still help to have a 10G update server with good peering in Asia and it would be nice having one around New York too. We don't need more bandwidth yet but people's download speeds could be improved.

We also have a bunch of services not consuming much bandwidth compared to updates where we need unmetered VPS or dedicated server instances in Asia. We also need a better way to do anycast for our self-hosted DNS servers. Our ns2 is currently BuyVM anycast which is missing Asia.

Changes in version 136.0.7103.44.0:

• update to Chromium 136.0.7103.44

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

Changes in version 135.0.7049.111.0:

• update to Chromium 135.0.7049.111

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

One of our two senior developers has been forcibly detained and conscripted to participate in a war. When they first went missing, we revoked their repository access as a precaution. We soon learned their disappearance was completely unrelated to GrapheneOS. Our priority has been keeping them safe.

We've used our available connections to try to keep them safe. There's no way to get them out of the conscription. However, they're an incredibly talented security researcher and engineer and it would be extraordinarily misguided to send them to front line combat. This seems to be understood now.

GrapheneOS development and updates have continued and will keep going. We have substantial funds available to hire more people to work on GrapheneOS. We'll need to hire multiple experienced developers to fill their big shoes. They'll hopefully be safe and when they return we'll have a bigger team.

If you're an experienced AOSP developer interested in working full time on GrapheneOS in a fully remote position, see https://grapheneos.org/hiring. We can pay people anywhere in the world via Wise (local bank transfers), BTC, ETH or XMR. We need people who can hit the ground running due to the current situation.

Our near term focus is going to heavily shift to Android 16 porting, maintenance and continuing to do better patching than standard Android 15 QPR2. An OEM providing us early access to Android 16 sources would help a lot and we wouldn't need to slow down new feature development nearly as much.

We felt obligated to go public about this but waited a couple weeks to make sure they were safe and that us going public wouldn't harm them. We avoided specifying the country or war to avoid involving GrapheneOS in a debate on forced conscription in an existential defensive war.

Changes in version 135.0.7049.100.0:

• update to Chromium 135.0.7049.100

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

Our initial highly experimental release for the Pixel 9a is now available for both CLI and web install via https://staging.grapheneos.org/.

We've tested both install methods and did basic testing of functionality including Wi-Fi, camera, audio, etc. Feedback is needed from users now.

We've tested the over-the-air upgrade path for the Pixel 9a internally via a sample update with no changes. We usually only use these sample updates internally for testing the upgrade path of each release. However, for broader testing, we're releasing it through each channel now.

First update from the initial 2025041200 release to the new 2025041201 release has no changes beyond build date and build number. The incremental (delta) update package is only 158KiB despite it shipping the full new firmware and OS images. We tested a full update package too.

Basic functionality has been tested for a while along with the upgrade path via both our System Updater app and recovery. It no longer needs to be considered highly experimental. Therefore, experimental Pixel 9a releases are now available on our regular production website too.

All of the standard Android and GrapheneOS functionality should already be working on the Pixel 9a including our hardware-based USB-C port control feature, hardware memory tagging, etc.

Main work was dealing with the temporary QPR1-based device branch (https://grapheneos.social/@GrapheneOS/114320149441258698).

GrapheneOS for the Pixel 9a support is no longer considered experimental. Since it's still based on Android 15 QPR1 upstream, it's missing some recent improvements in Android and GrapheneOS but we backported most post-QPR2 GrapheneOS changes and it'll be on mainline Android soon.

The fingerprint reader issue introduced by Android 15 QPR2 in March 2025 has been resolved by the monthly Android update for April 2025. This issue caused the fingerprint reader to become unavailable after reboot for a small subset of users nearly entirely on the non-Pro Pixel 9.

Android 15 QPR2 is the 2nd quarterly release of Android 15 and was released on March 4th. Our initial release based on it was on March 5th:

https://grapheneos.org/releases#2025030500

Our users reported the issue during our public testing for this release but it was impractical for us to resolve.

On March 8th, we made our 3rd release based on Android 15 QPR2 (https://grapheneos.org/releases#2025030800). Prior to it reaching the Stable channel later that day, we posted https://discuss.grapheneos.org/d/20636-workaround-for-android-15-qpr2-fingerprint-firmware-glitch-on-pixel-9 explaining how to work around the fingerprint issue and linked it across social media platforms.

Android's quarterly releases go through months of public testing. Despite all their internal and public testing paired with substantial development resources, they were unable to avoid this obvious issue shipping in March 2025. Their release engineering process is too inflexible.

It's quite likely that the issue already had a fix available prior to the March 2025 release. They require releases to go through weeks of internal testing/certification prior to publication and don't deviate from making 1 release per month, preventing shipping important fixes.

They have a strange approach where they have a bunch of important fixes ready to go but can't ship them because it would restart the final testing and certification process, delaying the release. It gets delayed all the way to the next month due to the inflexible release cycle.

There's a high chance this was a firmware-related issue where it wouldn't have been feasible for us to fix it. Our users reported it early in testing, but we couldn't reproduce it. Nearly every report we got was a non-Pro variant of the Pixel 9, only a couple reports elsewhere.

We're working on completing GrapheneOS support for the Pixel 9a. If you have a Pixel 9a and are interested in testing experimental GrapheneOS builds later today, please join our testing chat room on either Discord or Matrix which are bridged together.

https://grapheneos.org/contact#community-chat

Tags:

• 2025041100 (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 2025040700 release:

• full 2025-04-05 security patch level
• rebased onto BP1A.250405.007.D1 Android Open Source Project release
• remove code for Qualcomm XTRA (PSDS) privacy improvements since we no longer have any devices with Qualcomm GNSS and we can add it back in the future if we need it again rather than porting it forward under the assumption we'll be using it
• fix upstream RecoverySystem.verifyPackage(...) vulnerability (this was not directly exploitable due to there being 2 layers of update package signature verification and downgrade protection, but the first layer of protection should work properly to avoid a vulnerability in the 2nd layer being exploited)
• Android Debug Bridge: more complete fix for upstream use-after-free bug for network-based connections which is being caught by our always enabled hardware memory tagging support for the base OS in hardened_malloc
• kernel (6.1): update to latest GKI LTS branch revision
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.83
• Seedvault: update to 15-5.5 (will be replaced with a better backup implementation in the future)
• Vanadium: update to version 135.0.7049.79.0
• Auditor: update to version 88
• PDF Viewer: update to version 27
• PDF Viewer: update to version 28

Porting GrapheneOS to the Pixel 9a is now well under way. Pixel 9a is still using Android 15 QPR1 rather than Android 15 QPR2. We had to create a special branch for it based on taking our final Android 15 QPR1 release (2025030300) and rebasing it onto the Pixel 9a release tags.

Android 15 QPR2, 2nd quarterly release of Android 15, was released March 2025. Since Android 14 QPR2, quarterly releases are based off the development branch with as many changes as yearly releases. Many changes are behind feature flags and yearly releases enable far more flags.

Pixel 8a launched in mid May 2024 still using Android 14 QPR1 instead of Android 14 QPR2 released in March 2024. The device branch for the Pixel 8a went away the next month when Android 14 QPR3 was released. This year's June release is Android 16 rather than Android 15 QPR3.

We've backported a subset of the changes since 2025030300 to our Pixel 9a device branch including an import sandboxed Google Play compatibility layer, a recent fix for an upstream update security issue and all of our changes to our Network Location and System Updater projects.

Strangely, Android delayed the April 2025 monthly update until Pixel 9a launch day (April 10th) despite the Pixel 9a not receiving it. The monthly update is for Android 15 QPR2. Pixel 9a has April 2025 and earlier security patches backported to an Android 15 QPR1 device branch.

Since the Android 15 QPR2 monthly update and Android 15 QPR1 release for the Pixel 9a were released together, the kernel tags for the monthly update were delayed all the way until today in the past hour since the Pixel 9a tags took so long to push. We're dealing with that now.

To work around the monthly update for Android 15 QPR2 being delayed until Pixel 9a launch, we made a release based on April 2025 Android Security Bulletin backports on the day it came out (https://grapheneos.org/releases#2025040700). Android Security Bulletins are partial backports to old versions.

Android Security Bulletins are most of the High and Critical severity patches backported to older releases of Android including Android 15 without the monthly/quarterly updates. They're not the full Android security patches, just the subset required for OEMs to set a patch level.

Android Security Bulletins often contain backports of patches already shipped in earlier months. Various patches in the April 2025 Android security bulletin were already shipped by Android 15 QPR2 in March. The new Android release each month is a separate thing from the bulletin.

OpenSSL 3.5.0 was recently released with support for Post Quantum Cryptography (PQC). The package update is now deployed across our servers. Our web services now use hybrid PQC key exchange with clients supporting it. Easy to confirm X25519MLKEM768 gets used in Chromium browsers.

Notable changes in version 28:

• add back JPEG 2000 image support unintentionally removed in PDF Viewer version 27 due to pdf.js splitting it out
• add JavaScript fallback for JPEG 2000 image support for when the WebView JIT is disabled
• improve CMYK to RGB conversion when the WebView JIT is enabled via ICC profile support provided by the pure Rust qcms library compiled to WebAssembly

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to the network, files, content providers or any other data.

Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the APK assets along with blocking custom fonts since pdf.js handles rendering those itself.

It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with less access than it would have within the browser.

This app is available through the Play Store with the app.grapheneos.pdfviewer.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.grapheneos.pdfviewer id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Notable changes in version 27:

• update pdf.js library to 5.1.91
• raise minimum Chromium WebView version to 133 and use it as the build target
• add redundant setBlockNetworkLoads(true) for the WebView (this is already the default due to not having the INTERNET permission, but being more explicit about this is a good thing)
• update esbuild to 0.25.2
• update dependencies of npm dependencies
• update AndroidX Core KTX library to 1.16.0
• update Android Gradle plugin to 8.9.1
• update Kotlin to 2.1.20
• update Gradle to 8.13

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to the network, files, content providers or any other data.

Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the APK assets along with blocking custom fonts since pdf.js handles rendering those itself.

It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with less access than it would have within the browser.

This app is available through the Play Store with the app.grapheneos.pdfviewer.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.grapheneos.pdfviewer id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Notable changes in version 88:

• add support for Pixel 9a with either the stock OS or GrapheneOS
• require TLSv1.3 instead of either TLSv1.2 or TLSv1.3
• drop legacy USE_FINGERPRINT permission since we dropped Android 9 support a while ago
• update Bouncy Castle library to 1.80
• update CameraX (AndroidX Camera) library to 1.4.2
• update AndroidX Core library to 1.16.0
• update Guava library to 33.4.7
• update Android NDK to 28.0.13004108
• update Android Gradle plugin to 8.9.1
• update Kotlin to 2.1.20
• update Gradle to 8.13
• minor improvements to code quality
• exclude unused OSGI manifests to avoid file conflicts

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

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

GrapheneOS users must obtain GrapheneOS app updates through our App Store since verified boot metadata is required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Our 2025040700 release was an early April 2025 security update release based on the Android Security Bulletin backports.

April 2025 monthly release of Android 15 QPR2 is in the process of being published today and we'll make a new release after the tags are all pushed to AOSP.

Today is also the launch day for the Pixel 9a. The tags for the Pixel 9a should get pushed to AOSP after the monthly update is fully pushed.

Once that's pushed and we've released the April update of Android 15 QPR2, we can start working on adding Pixel 9a support to GrapheneOS.

We have a Pixel 9a ordered for our main device farm which has been marked as ready for pickup by the delivery company. It will hopefully be delivered tomorrow. We've generated signing keys and added preliminary support to Auditor and AttestationServer which will need testing.

April 2025 update for the Pixel 9a stock OS is still based on Android 15 QPR1 rather than Android 15 QPR2. They updated the device branch to the April 2025 security patch level via backports from Android 15 QPR2. Our initial port will be from our final Android 15 QPR1 release.

Our final Android 15 QPR1 release was 2025030300 which was the first Monday of March, which was the day the Android Security Bulletin was published so we made a similar early security update release based on it. Android 15 QPR2 was released the next day (March 4th).

Pixel 8a launched in a similar way based on Android 14 QPR1 instead of Android 14 QPR2. It was the first time it happened that way, and now they've repeated it with the Pixel 9a. It's strange to launch a new device on the previous major OS release with security backports instead.

Android 14 QPR3 was released less than a month after the Pixel 8a and it was merged into the mainline releases. It's not clear if the Pixel 9a will get an update to Android 15 QPR2 or move straight to Android 16 in June. Either way, it will have a device branch until Android 16.

Pixel 9a device branch tags are currently being pushed to AOSP. Kernel tags are going to be pushed after the non-kernel tags are pushed. That's means it will be a while longer before the monthly update is fully published. Going to make adding Pixel 9a support take a bit longer.

Changes in version 135.0.7049.79.0:

• update to Chromium 135.0.7049.79

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

Tags:

• 2025040700 (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 2025040400 release:

• full 2025-04-01 security patch level

Android Security Bulletin for April 2025 has 2 more vulnerabilities marked as being exploited in the wild.

GrapheneOS fully prevented exploiting both vulnerabilities for locked devices, made both far harder to exploit while unlocked and already had both patched for a while too.

CVE-2024-53150: heap overflow (read) in a Linux kernel USB sound card driverCVE-2024-53197: heap overflow (write) in a Linux kernel USB sound card driver

These vulnerabilities were being exploited by Cellebrite for data extraction from locked Android devices without GrapheneOS.

We have a post from late February about CVE-2024-53197 and 2 other bugs exploited by Cellebrite which they were blocked from exploiting by GrapheneOS:

https://discuss.grapheneos.org/d/20402-cellebrite-exploits-used-to-target-serbian-student-activist

CVE-2024-53150 is almost certainly part of the same batch of vulnerabilities they've been exploiting.

https://discuss.grapheneos.org/d/20401-grapheneos-improvements-to-protection-against-data-extraction-since-2024 covers how we've greatly improved the GrapheneOS defenses against these attacks since early 2024. We're continuing to work on improving it.

We helped get firmware security improvements to Pixels and are advocating for further hardware/firmware changes.

New 25Gbps sponsored server from Macarne is now handling all of our OS/package update traffic for Europe, Africa, Middle East, Central Asia and South Asia:

https://grapheneos.social/@GrapheneOS/114264453740567840

We're looking into the several offers we received for new servers in East and West North America.

Rolling out our recent relatively small OS update with an 70M delta to Stable for all devices uses ~2Gbps for ~6 hours in Europe after a short 3Gbps spike. It then gradually drops. Europe handles ~40% more than North America. Quarterly/yearly updates tend to be 400MB to 800MB.

We also need to figure out the separate issue of needing more VPS instances broadly distributed around the world for our network services like network time. We aren't yet sure how large our own Wi-Fi AP database for network location is going to be so we aren't sure on specs yet.

Tags:

• 2025040400 (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 2025032500 release:

• Sandboxed Google Play compatibility layer: remove StatsManager from hidden services and replace that approach with stubbing out all of the methods since Play services recently introduced new code using it that's missing a null check and triggers a null pointer exception which has blocked us from pushing out the newer versions of Play services beyond our App Store's Alpha channel
• Network Location: switch to making at most a single request to the service per position estimation by requesting up to 40 Wi-Fi APs at once
• Network Location: optimize making requests to the service for Wi-Fi AP data
• Network Location: optimize Rust JNI bindings to the point that it no longer causes a noticeable overhead without introducing unsafe code (it could be optimized further with unsafe code to cache more JNI binding work but the difference is insignificant so we don't plan to do it)
• Network Location: use correct Accept header value to more closely match macOS to avoid future compatibility issues
• fix upstream system_server crash from null pointer exception in F2fsUtils
• add infrastructure for more restricted access to global and per-user settings instead of allowing all system apps to read them and all privileged systems apps with the WRITE_SECURE_SETTINGS privileged permission to write them
• further restrict access to all global and per-user settings added by GrapheneOS with our new infrastructure
• replace disabling the unused ADD_USERS_WHEN_LOCKED and ENABLE_EPHEMERAL_FEATURE settings at boot with a new approach of making settings immutable in the code, which we can expand in the future to other problematic settings not used by GrapheneOS
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.131
• kernel (6.1): drop revert for upstream USB fix causing DisplayPort alternate mode regression due to another upstream patch successfully fixing it
• kernel (6.6): update to latest GKI LTS branch revision
• Vanadium: update to version 135.0.7049.38.0
• GmsCompatConfig: update to version 155
• GmsCompatConfig: update to version 156

Macarne has provided a sponsored server to replace our current EU update servers so we can handle current traffic and near future growth. Ryzen 9950X, 128GB RAM, 2x 2TB NVMe and most importantly 25Gbps bandwidth. It's greatly appreciated!

https://macarne.com/

We use GeoDNS and round-robin DNS to distribute load across our servers with automatic failover. Ideally, we can find a good 2nd provider willing to provide sponsored/discounted 2x 10Gbps servers to cover each coast of North America. 2x 25Gbps would be great but not needed yet.

Our existing setup was 8x 2Gbps OVH VPS instances with 4 in Quebec, 2 in France and 2 in Germany. This was getting increasingly overloaded for the 4 major releases per year, and the largest one (Android 16) is coming up soon. European bandwidth usage is also around 50-60% higher.

We currently have 16Gbps total bandwidth for our update servers and that's not nearly enough for major releases anymore. Rather than further scaling up our current 2Gbps unmetered VPS approach, we're currently looking into other options. OVH lacks cost effective 10Gbps servers.

We've made 2 attempts at talking to OVH about offering us something different than their publicly available products which hasn't gone anywhere. We likely need to move this part of our infrastructure to 1 or 2 other providers with unmetered 10Gbps dedicated servers like Tempest.

For an idea of what we're looking for, see the 10Gbps options at https://tempest.net/dedicated-servers with 64GB memory. They're also willing to give us a significant discount, which other major providers haven't offered. Tempest is currently IPv4-only though, which isn't ideal for our usage.