Vanadium version 135.0.7049.100.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/135.0.7049.100.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
- Edited
fluxcondensator Android does not use CUPS and doesn't passively scan for printers. The built-in print service only supports simple standard IPP, mDNS, etc. It's low attack surface and implemented mostly in a memory safe language (Java) for the baseline printing discovery and usage. Printing documents is the high attack surface part, not finding and using IPP printers. It's nothing like CUPS and doesn't have a bunch of complex and legacy drivers. Android delegates dealing with anything other than standard IPP support via users installed vendor print service apps.
Bullion It's an open source part of GrapheneOS from AOSP which exists to receive emergency alerts. There is no reason to be concerned about it. It receives and shows you the alerts if you don't have them disabled. It does not send data anywhere. The alerts are broadcasts and do not involve sending anything back. It has the minimal permissions it needs properly filter out irrelevant alerts based on their scope and to show them both on the phone it's running on and if relevant a paired companion device like a smartwatch.
Bullion Absolutely not. It's a receive-only app for showing emergency alerts to the user on their phone and paired smartwatch. It doesn't send data anywhere.
Even more recent patches (look at AOSP monthly security bulletins) still fix critical bugs in Wi-Fi subsystems that run before Android's SELinux sandboxing even kicks in.
There's no point at which relevant code runs before SELinux is set up. It's active from shortly after the init process starts.
That’s exactly why attackers look at external vectors like Wi-Fi. Firmware on Broadcom chips is opaque, proprietary, and often lacks full exploit mitigations like CFI or stack canaries. That means driver and firmware fuzzing — especially over SDIO or PCIe — remains a fruitful attack surface.
It has gotten a lot less bad over the years including with Google's help. There has been IOMMU isolation for Wi-Fi since the Nexus 5X and it's one of our hardware requirements.
The WIFI module is not IOMMU isolated.
This is not correct. It has been isolated on all Pixel devices. It has Nexus devices before the Nexus 5X without it isolated.
Nuttso It's better than it used to be and it switched from Atheros to Broadcom other than the Pixel 7a.
Jules-Przla You appear to have a network issue causing
rl01p.sfg-mkg.deto fail DNS resolution. It's unable to convert the name to an IP address due to a network issue. This is an issue with your network connection, VPN or Private DNS configuration. It's not an issue caused by the OS.We've seen apps doing this a few times before and have an idea of why it's happening. It's incredibly rare and caused by a misguided and broken attempt at anti-tampering. It will also likely break in future Android releases and with certain OEM variants of Android. They're likely using some debugging functionality to check the initial call stack and are hard-wiring specific permitted call stacks. Secure spawning has a slightly different initial call stack from how it starts differently. It's possible we can make it align or at least fake it so these apps stop banning GrapheneOS when secure spawning is enabled.
Calls remain broken as I toggled on VoLTE but the option disappeared now and the phone still tries to use it but fails.
Reset cellular settings again, then reboot.
I agree that making assumptions is inappropriate but I still stand with this bug being unacceptable. Breaking the phone functionality of a phone should not happen.
Nothing went wrong for other users including those on the same carrier. It's entirely possible your carrier provisioned new settings after the update but it was screwed up.
andrej567 Does not seem related to this.
- Edited
huberto This is currently how it's intended to work because the OS location services are global and the Network Location app runs as part of the Owner user. The OS doesn't have separate location services for each user but rather global services used from each user.
upstage4186 Turn off developer options as a starting point. Try with and without smooth display enabled in the display settings too.
UpStream That's unclear at this point. We may be able to make a minor change to get it working again similar to what we did to get Revolut working again.
BaronAfanas How many are you registering? Try only registering 1 in a single profile to start.
I have tried resetting mobile network settings and APNs. It did not fix it.
Try fully turning it off without a USB-C cable connected, waiting a couple seconds and turning it back on.
Similar issue with a Pixel 7 since build 2025041100.
Did you already reset cellular settings via Settings > System > Reset? Did you already try powering off the device and then turning it back on again rather than just a reboot?
This kind of bug should not happen even with a single developer working on the project.
We have far more than one developer working on the project. There were no issues reported during either Alpha or Beta testing. We can't work on issues which aren't reported to us. The way you're approaching this is not appropriate.
0xsigsev The data is always encrypted, it's just available to the OS to access After First Unlock. It doesn't stop being encrypted on the storage though.