@[email protected] We added a note about when the full 2026-06-05 Android patch level was shipped to clarify this. Backported the Mali kernel driver update from Android 16 covered the 2025-06-05 Android patch level but not the 2025-06-05 Pixel patch level mainly because that includes RIL patches and we needed to backport those too. We also don't know if the Wi-Fi and Bluetooth patches in the Pixel bulletin are in the drivers or firmware so we updated the firmware in the most recent release too.
GrapheneOS
joined 2 years ago
@[email protected] No, what's written there is correct. This release provides the Pixel 2025-06-05 patch level. An earlier release provided the Android 2025-06-05 patch level. Those are distinct things. The displayed patch level is Android + Pixel for Pixels. We usually just mark the full combined patch level in the release notes. In many cases when we ship the 2025-06-01 patch level, that's also the Android 2025-06-05 patch level but not Pixel until the Pixel release is out and incorporated.
We can potentially backport our Android 16 kernel builds as a whole. We'll also need the Exynos RIL updates and some other things.
Our completed Android 16 port has been going through testing to find/fix regressions. Most development time is going into redoing device support.
This release includes the Android 16 SoC firmware and Samsung cellular radio firmware updates. We'll be doing a follow-up release with backports of the other Android 16 Pixel bulletin patches. This first phase has lower risk of regressions and has the only critical severity ones.
@[email protected] You're likely on a Pixel 9a but not yet updated to the latest OS release, which is needed to resolve this issue. Our port of removing the Play Store's "Automatic protection" injected code to the Pixel 9a device branch broke updating system apps out-of-band because of an upstream Android issue in Android 15 QPR1 which was resolved for Android 15 QPR2. The issue was quickly resolved after it was reported.
We test the OS upgrade path before releases but not updating apps out-of-band.
@[email protected] Android 15 QPR2 was released in March, so our support for the Pixel 9a is based on taking our last Android 15 QPR1 release from early March and rebasing that onto the Pixel 9a device branch based on Android 15 QPR1, then backporting the GrapheneOS changes from March and later to it. We didn't backport everything and it doesn't have the improvements in Android 15 QPR2 itself yet. Once it's moved to Android 16, it will be part of their regular releases and therefore also ours too.
@[email protected] Pixel 9a was a recently launched device and is supported via a special Android Open Source Project / stock Pixel OS device branch based on Android 15 QPR1. The main GrapheneOS releases are based on Android 15 QPR2. Android 16 is being released this month, possibly tomorrow, and the Pixel 9a will be supported as part of mainline Android after that happens. The same thing happened with the Pixel 8a at launch, where it was still based on Android 15 QPR1 instead of Android 14 QPR2.
@lka1988 We focus our effort on the base OS and areas which are not already covered by high quality open source apps. We don't need to build our own domain-based filtering and blocklists for it because they already exist.
We have built-in content filtering in Vanadium based on EasyList + EasyPrivacy. That's more usable (per-site toggle) and much less limited than what domain-based filtering can do but it's still limited by needing to permit dual use functionality and is still easily bypassed.
> Plus, in the first comment, you suggested “RethinkDNS”, which depends on their own DNS servers.
You do not need to use their DNS servers. You can use local filtering and your choice of DNS servers including the network provided ones.
> I wouldn’t think a security and privacy-focused ROM should be recommending anything but a locally hosted option.
We're recommending using local filtering via RethinkDNS, not the RethinkDNS servers. They allow downloading the blocklists locally.
You can see from https://eylenburg.github.io/android/_comparison.htm that we have no limitations on call recording while others do. The fact that it's manual means users are taking responsibility for it each time. It's little different than recording a call with a tape recorder on speaker phone. If we did it automatically, then users would not be making a conscious decision to enable it case-by-case. That would be a problem, and not an acceptable way to do it without an extra explicit opt-in.
view more: next ›
@[email protected] We need to do another release today to fix an issue with the RIL backports but then it should be good to make it through Alpha and Beta testing to reach Stable, unlike the most recent release which had call related regressions reported very quickly in Alpha testing which are now resolved.