@[email protected] It won't be ported to Android 15 because it would require a lot of our resources while creating a lot of regressions for Pixel 5 users. It would take a long time for it to become stable with Android 15 since it has no official support for it and would need a bunch of hacks to make it work. We'd need to switch to using a prebuilt vendor.img built from Android 14 QPR3 and combine that with Android 15. It'd theoretically work but in practice lots of bugs and lots of work.

@[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.

@lka1988 @pineapplelover

> System-wide hosts-based adblocking

That's not a good way to do it.

> DNS/always-on VPN is not a reasonable solution

You don't need to use a DNS service or VPN service to filter remotely. You can filter locally via the VPN service feature, including while using a VPN if you want.

You should follow our advice and do it with an app like RethinkDNS providing support for both local filtering and optionally using WireGuard VPNs at the same time including chained VPNs.

@jfr_1980 @lineageos @keepandroidopen It makes far more sense to use LineageOS itself rather than a sketchy fork from an organization and company which have engaged in years of attacks on actual privacy projects. Giving money to Murena is contributing to harming actual privacy and security efforts on mobile. Using /e/ hands your data to authoritarians on a silver platter. It's far less defended against attacks than using an iPhone. No surprise governments against secure devices are funding it.

@[email protected] Pixel 5 has been end-of-life since December 2023 after the last update in November 2023. It hasn't received driver and firmware updates since then. We provided what we could with very limited resources available for insecure devices via the Pixel 5a still being supported, but the Pixel 4a (5G) and Pixel 5 had significant regressions with each quarterly release we had to work around. A15 would cause enormous problems and we don't need to port it to 15 to keep it working for another year.

@lka1988 @pineapplelover

Why do you want to have a slow, legacy and hard to debug implementation of domain-based filtering instead of managing it with an app?

Domain-based filtering is also very limited in what it can since it's trivially bypassed by apps or web sites using IPs or doing their own DNS resolution, which is fairly widely adopted. For example, WhatsApp will still work with the domains blocked. In practice, you'll also only be filtering domains not used for useful functionality.

@[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

> 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.

@jfr_1980 @lineageos @keepandroidopen Instead of doing local processing for speech-to-text as Apple and GrapheneOS are doing, /e/ has a supposedly private service for it which actually just sends the sensitive user data to OpenAI and calls it anonymized since they pass it through their own servers:

https://community.e.foundation/t/voice-to-text-feature-using-open-ai/70509

It's representative of their approach. You should read https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private and the third party content from Divested Computing, Mike Kuketz and Eylenburg linked there.

@jcs The definition of openness used by Librem 5 is that a fully closed source device with closed source firmware and software would be open and freedom respecting as long as none of the firmware/software can be updated.

Purism prevents updating firmware for the SoC and calls it open even though the SoC is fully closed source hardware and does have closed source firmware, which just can't be updated. They don't count secondary components like radios. 99.999% closed source hardware isn't open.

@jfr_1980 @lineageos @keepandroidopen Murena are scammers who have heavily invested in destroying GrapheneOS. That includes the founder of /e/ and Murena (Gaël Duval) actively participating in harassment towards our team. He has repeatedly spread harassment content from Kiwi Farms and even a blatant neo-nazi website.

SailfishOS was made in close partnership with the authoritarian Russian government.

The values of the people involved in both organizations are atrocious and no allies of ours.

@jfr_1980 @lineageos @keepandroidopen /e/OS is a fake privacy project. It has very poor privacy and extraordinarily poor security. It fails to provide users with basic updates and protections. They market it as private but yet have user tracking, send sensitive user data to third party services without consent and fail to keep up with basic privacy patches/protections. They market it as degoogled and yet is has far more Google services and privileged Google app/service integration than AOSP.

@shiva @informatica @informapirata We don't think these are good recommendations for users who care about privacy and security. There's a lot more to privacy than simply avoiding Google apps/services.

We recommend https://eylenburg.github.io/android/_comparison.htm for a high quality comparison between Android-based operating systems. The other OSes listed there do not keep up with privacy/security patches which is the bare minimum. CalyxOS updates have also recently been discontinued as a whole (https://calyxos.org/news/2025/08/01/a-letter-to-our-community/).

@andreabont @informapirata @morrolinux @gnulinuxitalia We only recommend that apps already using the Play Integrity API and unwilling to remove it move to using this instead. This enables them to support arbitrary other devices and operating systems. Other attestation roots can be supported along with arbitrary alternate operating systems via allowing their verified boot keys. That's much better than the Play Integrity API. We'd prefer if apps didn't check the device/OS but they insist on it.

@lka1988 @pineapplelover

GrapheneOS does add call recording to our fork of AOSP Dialer. Unlike most alternate operating systems including LineageOS, we don't limit the regions where it's available. The fact that users are choosing to use it for specific calls means users are taking responsibility for the legality of recording that specific call and informing the other person of it. Automatic call recording would need more complexity to make it practical for people to comply with recording laws.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.

@lka1988 @pineapplelover

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.

@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.

@jcs Librem 5 has a fully closed source SoC, which means System on a Chip as opposed to a traditional desktop where the components would be part of a motherboard. The board schematics are for a basic PCB. It's a nearly entirely closed source device in terms of where the actual complexity is. The SoC is the core component providing nearly all the base functionality. The SSD, memory, touchscreen, battery, Wi-Fi, Bluetooth, cellular, etc. are all closed source, as are various other chips, etc.

@jfr_1980 @lineageos @keepandroidopen Yet all of those are largely made with US tech. You're going to need to avoid the Snapdragon, the Linux kernel and a massive amount of other tech if you want to avoid technology primarily made and controlled within the US. A company being geographically located within the US doesn't mean the components and software they're using aren't largely US tech.

Europe is leading the charge on age verification, cracking down on end-to-end encryption, etc. not the US.