GrapheneOS [Unofficial]

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

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.

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.

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

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.

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.

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.

Yuh app from Swissquote temporarily disabled Play Integrity API enforcement due to complaints from GrapheneOS users and is reimplementing their security checks with support for GrapheneOS based on https://grapheneos.org/articles/attestation-compatibility-guide. We removed it from the list of apps banning GrapheneOS.

See https://github.com/PrivSec-dev/banking-apps-compat-report/issues/509#issuecomment-2753783269 for details. They responded on the issue.

This is one of several apps which has recently stopped banning GrapheneOS due to the guide we provide on using hardware-based attestation as an alternative or full replacement for the Play Integrity API.

Apps enforcing enforcing a Play Integrity API check have nothing to lose by permitting GrapheneOS too via hardware attestation. You'll get positive reviews from our rapidly growing userbase instead of negative. GrapheneOS is much more secure than anything Play Integrity permits.

Changes in version 156:

• add stub for MediaRouter2.getInstance() to avoid a silent crash

A full list of changes from the previous release (version 155) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Android has always taken the approach of it being developed in private and then having the full sources and commit history published for each stable release. This approach used to be the norm for open source software many years ago, but now most projects do a lot of their development in the open.

Commit history being available also didn't used to be the norm many years ago but rather only tarballs for releases. It's very important for them to provide it and they're still going to be doing that.

Certain sub-projects were developed in the open as part of the public Android Open Source Project repositories in the main branch but the bulk of the work was done in private. They maintained both a public main branch and an internal development branch and had to merge back and forth between them.

Recently, Google announced they'll be shifting most of the small subset of the OS developed in the AOSP main branch to being developed internally instead. The full commit history will still be available when stable releases are published as it for the majority of AOSP developed that way already.

AOSP main was not where most of the OS was developed and would get most of those changes merged into it shortly after each stable release.

AOSP main also doesn't correspond to Developer Preview and Beta releases, which are separate branches and what we need for porting before a Stable release.

The small subset of the OS developed via AOSP main moving away from it won't have a major impact on GrapheneOS. It did not provide us with early access to the code we need for porting GrapheneOS to an upcoming release before the day it gets released. That already required having partner access.

Android is remaining open source and simply being slightly less open about the development of certain components. We won't be able to see the commits as they're made for that small subset of components anymore but rather need to wait until they publish the full commit history for stable releases.

In contrast with Android, Chromium is developed almost entirely in the open and we can port and test all of our changes to the upcoming releases before there's a Stable release. This is very helpful and makes maintenance much easier for us. Doing this for Android already required partner access.

We've already been in the process of figuring out how to get partner access in a way that will be reliable and long term. There was only one year where we had early access to a new major release. We haven't had it for several years and we still manage to get the yearly releases out in a couple days.

Changes in version 155:

• disable AnomalyConfigIntentOperation to avoid a null pointer exception from the StatsManager service not being accessible
• update Android Gradle plugin to 8.9.1
• update Gradle to 8.13

A full list of changes from the previous release (version 154) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

Murena sells highly insecure devices without basic privacy/security patches or the standard privacy/security model intact. Direct opposite of GrapheneOS in regards to privacy and security. It also lacks the stability and app compatibility of GrapheneOS...

https://xcancel.com/gael_duval/status/1905171960138547267

Murena, the company behind /e/OS, heavily pushes using both an insecure OS and services. Their services lack end-to-end encryption and are the opposite of private. People purchasing their devices are making a huge privacy and security sacrifice compared to simply using an iPhone.

Murena misleads people into wrongly believing that GrapheneOS is harder to use as their CEO is doing there. GrapheneOS has far better app compatibility, far better stability and unlike /e/OS is a serious production quality OS keeping up with updates and keeping things working.

/e/OS is a fork of LineageOS, a volunteer developed project focused on broad device compatibility and power user features rather than privacy or security. /e/OS is a security disaster even compared to LineageOS with far longer update delays and far more security regressions.

Despite all the money Murena makes selling overpriced insecure devices and grifting EU government funds, they aren't even able to keep their non-end-to-end encrypted services up. Those services were recently down from early October until mid-February. That's not remotely serious.

Here's another example of the CEO of Murena replying to a post about GrapheneOS trying to mislead people about it and promote their products:

https://xcancel.com/gael_duval/status/1904097790977810458

Here's a high quality third party comparison between Android-based operating systems:

https://eylenburg.github.io/android_comparison.htm

Here's another on X:

https://xcancel.com/gael_duval/status/1887528529694273590

Gaël Duval consistently misleads people about the ease of obtaining GrapheneOS, app compatibility, usability and privacy. These desperate posts on X, Mastodon and elsewhere are a small fraction of it. It's Murena's company policy.

Changes in version 135.0.7049.38.0:

• update to Chromium 135.0.7049.38
• backport SDK update to API 36 (Android 16) for early testing of the Vanadium WebView on Android 16

A full list of changes from the previous release (version 134.0.6998.135.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 latest 2025032500 release greatly improved our built-in network-based location. It's usually better than Google's network-based location in urban areas where Apple has competitive data. Unlike Google's service, position estimation is done locally by fetching location data for nearby networks.

You can enable this feature via the toggle we added at Settings > Location > Location services > Network location. You can optionally enable the standard Wi-Fi scanning toggle in the Location services menu to allow Wi-Fi scans when Wi-Fi is otherwise disabled to keep network-based location working.

Our implementation is currently based entirely on Wi-Fi Access Points (APs). Location data for nearby APs is fetched in batches from either Apple's service or a GrapheneOS proxy server. We also ask the service for up to 100 nearby APs which it provides with a reasonable density over a large area.

Our implementation caches location data for up to 10000 APs in an in-memory Least-Recently-Used cache with 15 minute expiry after last usage of an AP. This avoids persisting a local location history while enabling semi-offline usage. We can make these parameters user configurable in the future.

Most navigation apps use the fused location service providing the best result from GNSS (GPS, Galileo, etc.) or network-based location (when it's enabled). Other apps often prefer network-based location for lower power usage and quicker results not requiring GNSS reception. Some apps can't use GNSS.

Most apps on the Play Store use the Google Play services location service instead of the OS provided location service. By default, our sandboxed Google Play compatibility layer reroutes location requests from these apps to the OS location service so there's no need to give Location to Play services.

Nearly all users on Google Mobile Services devices have their network-based location enabled. This means some apps assume it's always available. For improved compatibility, our default enabled rerouting emulates the presence of network location with GNSS when the OS network location service is off.

In the near future, we'll be making several major improvements to our network location service including Wi-Fi RTT (Round-Trip-Time) for improved distance estimation and cell tower fallback to make it work better outside cities. There will also be a lot more efficiency and other improvements to it.

Longer term, we'll be providing our own location service rather than only a proxy along with full offline support via database downloads. It already works offline for a while based on the cache. We'll be using data from Apple's service to bootstrap our service, but we'll also be using other sources.

Source code is available here:

https://github.com/GrapheneOS/platform_packages_apps_NetworkLocation

It's new code and still being built out so it hasn't had much refactoring, optimization or tuning yet. It's a mix of Kotlin and Rust since we wrote position estimation in Rust for significantly better performance.

Tags:

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

• Network Location: rewrite position estimation in Rust (from Kotlin) with a new algorithm based on Expectation-Maximization (EM) always using 3D (altitude) to provide much better accuracy, robustness and performance (this new 3D implementation performs better than the previous implementation in the 2D mode we were stuck using due to 3D being far too CPU intensive)
• Network Location: improve RSSI-based (signal strength) distance estimation including tuning it separately for 2.4GHz vs. 5GHz/6GHz and take distance variance into account for position estimation (Wi-Fi Round-Trip-Time support will be added in the future for Access Points supporting it)
• Network Location: add support for 6GHz Wi-Fi networks via Reduced Neighbor Report (RNR)
• Network Location: increase the number of closest APs we explicitly request data for from 5 to 15
• Network Location: request data for up to 4 APs at a time instead of only 1 to improve networking efficiency
• Network Location: make our requests more closely match a current macOS release to avoid future compatibility issues and to get Apple's service to provide more than only 2.4GHz networks as nearby networks in response to queries
• Network Location: reduce requesting data for 100 additional nearby Wi-Fi APs down to 8 APs when a decent amount of additional results were returned from a recent request for up to 100 in the past 10 seconds
• backport upstream brightness fluctuation fix from Android 16 Beta 3.1
• Sandboxed Google Play compatibility layer: fix Location Accuracy link with Play services 25.09 and later so we can ship it as an update for users with sandboxed Google Play installed
• Sandboxed Google Play compatibility layer: remove no longer supported "Configure Play Store updates" settings since we always handle updates ourselves via our App Store now
• fix an upstream screenshot process crash in ScrollCaptureController
• Terminal (virtual machine management app): backport upstream improvements including detecting an outdated image to providing an upgrade path and removing the artificial cap on disk resize
• Vanadium: update to version 134.0.6998.135.0
• only block installing out-of-band APEX updates on production (user) builds since it's useful for development
• add support for testing Android 16 Beta 3 feature flags for development builds
• begin porting our changes to work with Android 16 feature flags

Changes in version 134.0.6998.135.0:

• update to Chromium 134.0.6998.135

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