@34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095@mostr.pub @5cad82c898ee66013711945d687f7d9549f645a0118467dae2f5e274c598d6ff@mostr.pub @b98ded4ceaea20790dbcb3c31400692009d34c7f9927c286835a99b7481a5c22@mostr.pub @3c26e8ae08c3700ea0429fd56f4862d3b51955c8e3286cc0e01a01875281bd88@mostr.pub We could work around that by handling Lightning donations as donations directly to developers without involving the GrapheneOS Foundation. However, we wanted to be moving towards using the GrapheneOS Foundation instead of away from it.

@34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095 @5cad82c898ee66013711945d687f7d9549f645a0118467dae2f5e274c598d6ff @b98ded4ceaea20790dbcb3c31400692009d34c7f9927c286835a99b7481a5c22 @3c26e8ae08c3700ea0429fd56f4862d3b51955c8e3286cc0e01a01875281bd88 Supporting Lightning requires us to figure out how we’ll need to handle that for our accounting and auditing requirements. We’re required to have a record of every donation to GrapheneOS. Auditors may not know what to do with Lightning.

@[email protected] Yes, we added support for that. It doesn’t support auto-locking and it’s possible for it to not be in the expected UI state initially but it does work other than that. We’ll add in the missing bits over time.

@[email protected] The issue you experienced has been reported by a dozen other Pixel 8 users recently and isn’t related to any of our recent updates. It has possibly been an issue since Android 15 QPR2 in March or possibly only since the April monthly update. It’s not known what’s causing it and no one has provided any logs showing any crashes or anything else that’s helpful, likely because people can’t really do much with the device once it happens. This means we don’t know much about the cause.

@astroboy That doesn’t mean it was caused by an update and it fact shows that it almost certainly wasn’t related. You had an update installed and waiting for you to reboot the device. The issue causing it to lock up with a black screen occurred on an old version of the OS prior to the 2025042500 release. When you forced it off and turned it on, you booted 2025042500 for the first time. That implies you weren’t on 2025042500 yet. If it had failed to boot repeatedly it’d have been rolled back.

@astroboy Try plugging the device into a wall charger and then turning it off completely. Hold volume down while it reboots so it boots into fastboot mode instead of the OS. While it’s plugged in and in fastboot mode, turn off the device from there and let it charge for a while. Then, see if it works properly after it has been charged for at least around 10 minutes.

@[email protected] Hold power for a minute or longer.

Which device model do you have? Is it an 8th generation Pixel?

There’s something wrong with 8th generation Pixels since perhaps around Android 15 QPR2 in March 2025 which can cause the device to become unresponsive until forced off. It can be a problem to get it forcefully turned off. It appears to be some kind of upstream Android bug or Pixel firmware bug. We don’t know if it happens more often with GrapheneOS. The May update will hopefully fix it.

@[email protected] There’s a known upstream Android bug impacting 8th generation Pixels which can cause them to become unresponsive with a black or frozen screen. The device remains booted and functioning when that happens so trying to boot it isn’t going to work because it’s already turned on and still mostly functioning. You have to long press the power button to force the device off if you’ve encountered that issue. It might be a GPU bug introduced in Android 15 QPR2 but we haven’t determined it yet.

@[email protected] That’s extraordinarily unlikely and you’re likely misdiagnosing it.

OS updates are tested on each device model before reaching Alpha and go through both Alpha and Beta testing before Stable. This OS update hasn’t reached the Stable channel yet.

OS updates happen in the background and kick in after rebooting. There’s a toggle to automatically reboot after updates while idle in the System Updater settings but it’s disabled by default.

If an update fails to boot, it gets rolled back.

deleted by creator

@[email protected] @[email protected] We backported most of the GrapheneOS features, bug fixes and improvements which were made after Android 15 QPR2 was launched. We didn’t backport any of the Android 15 QPR2 features or bug fixes though. The stock OS is based on Android 15 QPR1 so it’s not as if GrapheneOS would be worse due to this, it’s just behind the Android version used by the other devices we support. That will change in a bit over a month when Android 16 is released. It will be on mainline Android after that.

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

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

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

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

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

@[email protected] They saved time not porting either to the QPR2 release prior to launch. It wasn’t as noticeable for the Pixel 8a since Android 14 QPR3 was launched weeks later and provided mainline Android support for it. It’s more noticeable for the Pixel 9a since it launched in April instead of late May.

Android 16 is coming out this year in June instead of that being the QPR3 release as usual. We aren’t sure why. It’s possible they decided to move the month yearly releases come out going forward.

deleted by creator

@[email protected] You can see from https://grapheneos.org/releases#tegu that it’s not on the same version of GrapheneOS as the other devices.

It’s normal for new devices to launch with a device branch. Pixel 8a and Pixel 9a are the first non-flagship devices launched after trunk-based quarterly releases started with Android 14 QPR2.

Pixel 8a launched with Android 14 QPR1 in May 2024 instead of QPR2 from March 2024. Android 14 QPR3 was released weeks later in June, merging it into mainline Android. This is similar.