Macarne (https://macarne.com/) 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!
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.
#GrapheneOS
Final
final@stacker.news
npub1hxx7...g75y
Digital forensics and security specialist part of the GrapheneOS project.
Posts my own and not endorsed by my employer. AI slop and Nostr DMs ignored.
Matrix: f1nal:grapheneos.org
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, but it would be open source without it. They're still going to be providing it.
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.
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:
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.
#GrapheneOS
GitHub
GitHub - GrapheneOS/platform_packages_apps_NetworkLocation
Contribute to GrapheneOS/platform_packages_apps_NetworkLocation development by creating an account on GitHub.
Second donation to GrapheneOS by the Proton Foundation


GrapheneOS Discussion Forum
Second donation to GrapheneOS by the Proton Foundation - GrapheneOS Discussion Forum
GrapheneOS discussion forum
#GrapheneOS version 2025032100 released.
This update enables the new, improved Desktop Mode as a developer option. Feel free to try it all out.
• Sandboxed Google Play compatibility layer: improve support for overriding Gservices flags to avoid situations where our overrides aren't used leading to compatibility issues (this should fix a recent Play services crash that's being reported)
• Sandboxed Google Play compatibility layer: improve support for overriding phenotype flags and fix flag overrides not being applied in some cases
• fix 2 upstream lockscreen layout bugs with split shade used on folding phones (for the inner screen) and tablets
• fix upstream lockscreen layout bug with placement of alarm and Do Not Disturb information
• fix upstream lockscreen layout bug hiding date text when media is playing
• enable support for the new desktop mode as an additional developer option toggle (Pixel Tablet already has this as the main toggle)
• Terminal (virtual machine management app): backport upstream improvements
• System Updater: raise download buffer size
• System Updater: delete update package immediately after completion
• System Updater: fall back to downloading and installing a full update if an incremental (delta) update fails initialization which occurs when a firmware or OS image has been corrupted (extremely rare edge case due to verified boot)
• System Updater: retry faster if installation fails
• System Updater: improve error checking to provide better error messages
• System Updater: close update package zip file earlier
• Network Location: require TLSv1.3 for GrapheneOS services instead of either TLSv1.2 or TLSv1.3
• kernel (6.6): update to latest GKI LTS branch revision
• Seedvault: update to 15-5.4 (will be replaced with a better backup implementation in the future)
• stop disabling inclusion of device diagnostics functionality now that it's available in the Android Open Source Project
Releases | GrapheneOS
Chromium team developed a new font rendering library (Skrifa) as part of their Fontations library written in Rust. Skrifa now provides memory safe rendering for all web fonts since Chromium 133 for Android, ChromeOS and other Linux distributions:
The above article lists examples of vulnerabilities exploited in the wild contained within the FreeType renderer that it seeks to replace.
This is a post from 2022 about Android about the increased use of memory sage languages.
> Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language.
Android has much more heavily adopted Rust since then. It's nice to see Chromium starting. This provides significant benefits to #Vanadium and #GrapheneOS users.

Chrome for Developers
Memory safety for web fonts | Blog | Chrome for Developers
Learn how and why the Chrome team has replaced FreeType with Skrifa.

Google Online Security Blog
Memory Safe Languages in Android 13
Posted by Jeff Vander Stoep For more than a decade, memory safety vulnerabilities have consistently represented more than 65% of vulnerab...
New #GrapheneOS Vanadium browser release in Alpha supports passkeys without Google Play Services using the Android 15 credentials manager. Not every passkey provider supports it, but you won't need Play if yours does.

GitHub
Release 134.0.6998.108.0 · GrapheneOS/Vanadium
Changes in version 134.0.6998.108.0:
update to Chromium 134.0.6998.108
add support for using passkeys without Play services via the Android 15 cre...