GrapheneOS
Open source privacy and security focused mobile OS with Android app compatibility.
- 86 Posts
- 58 Comments
@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.
deleted by creator
@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.
2·3 days ago@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.
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.
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.
> 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.
@xeekei@mastodon.world 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
@xeekei@mastodon.world 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.
@xeekei@mastodon.world Pixel 9a is a newly launched device which is not supported by mainline Android. It still has Android 15 QPR1 with the stock Pixel OS instead of Android 15 QPR2 and it’s the same with GrapheneOS. It does not receive the regular releases of GrapheneOS yet and does not have the full Android or GrapheneOS feature set. It will have mainline Android with the launch of Android 16 in June. Until then, it has special releases using a Pixel 9a device branch based on the upstream branch for it.
@deepblue@social.tchncs.de It’s one of the planned features. It’s being actively worked on again so it should improve a lot more than it has in the past several years where no significant work went into it.
@lewis@weird.autos It won’t be a major change because the parts we needed most to port our changes early were already not developed in public. It will be a minor reduction in what we have available early, which is a step in the wrong direction but not a large one. We’re working on getting partner access so we can port everything early without relying on it being public early.
See our response thread at https://xcancel.com/GrapheneOS/status/1905023779757015397#m for more details. Linked to the last post in the thread because it works better.
@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.