GrapheneOS

@astroboy@fosstodon.org 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.

@astroboy@fosstodon.org 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.

@astroboy@fosstodon.org 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.

@astroboy@fosstodon.org 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.

@kgw@cosocial.ca @xeekei@mastodon.world 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.