T

ToughDBlue

GrapheneOS We've fixed this and will be starting the official builds for a new release soon.

oldschoolmemories It's for running other operating systems in a virtual machine, not running them side-by-side with the main OS. Stock Pixel OS is built to run on Pixels, not in a virtual machine. GrapheneOS builds for the virtual machine environment can be added eventually and turned into a way to seamlessly run apps in a virtual machine.

The best thing for battery health will be using the battery optimization feature and leaving the device plugged in as much as possible to take advantage of bypass charging instead of repeatedly draining and charging the battery. It needs to have proper USB-PD for that to work well, so disabling fast charging would be at odds with the bypass charging feature.

The OS only displays how many cycles were made on the battery, is there a way to check the % health of the battery?

It estimates the capacity but it's not shown in the regular user interface as far as we know. You can check it via ADB shell via /sys/class/power_supply/battery/charge_full but we don't recommend using ADB on a production device. We could potentially add the info to the Settings app.

ToughDBlue Appreciate the info. Will try it out if the one above you isn't to my liking.

0xsigsev Source please.

It's a real narrative that some have tried to push. There's no doubt some criminals use GrapheneOS, but I get the feeling they're outnumbered by the rest of us. Anyone who spends some time in our community will find that average GrapheneOS users are simply people who care about their privacy and the security of their devices.

Although I understand the basic idea, I personally think it is of little value to hide the GrapheneOS logo on boot (personal side note: I would rather like to remove the Google logo):

Besides the arguments already mentioned by Xtreix and other8026 : How often do you reboot your phone and especially how often do you reboot in public? Wouldn't you rather try to avoid that because you have to enter your long BFU password in front of prying eyes and/or surveillance cameras?

We're starting with testing via sideloading rather than moving it right to Alpha. Join our testing chat room if you want to help with this. It's available for everything other than the Pixel 7a already and that should be available soon.

https://grapheneos.org/contact#community-chat

GrapheneOS version 2025030500 released:

https://grapheneos.org/releases#2025030500

See the linked release notes for a summary of the improvements over the previous release.

Boyz For privacy reasons it would be better to be able to have an option to hide the grapheneOS logo when the device starts .

This has already been discussed several times, hiding the GrapheneOS logo is not a privacy feature, it's not planned at all and many users want to see the logo at startup.

Boyz _ As well as the possibility of configuring a constraint password putting the device in bfu mode and possibly allowing an SMS to be sent to certain of our contacts by SMS indicating that your device is probably no longer secure.

GraphenOS supports duress passwords in settings > security and privacy > device unlock >duress password. GrapheneOS uses automatic reboot in settings > security and privacy > exploit protection > automatic reboot, If the device has not been unlocked within this time lapse, it will restart to return to BFU mode.

Sending SMS is not private and secure and let's say the device is compromised, I doubt very much that a remote person could do anything about it. GrapheneOS uses a verified boot and protects itself well against persistence, reboot the device if you think something is wrong.

ToughDBlue Got it. Thank you.

ToughDBlue Thank you! (Only GmsCompat is running in the background.)

GrapheneOS version 2025030200 released:

https://grapheneos.org/releases#2025030200

See the linked release notes for a summary of the improvements over the previous release.

ProfessorMonks 5G means 5G or below, which allows using all the supported protocols. It provides maximum compatibility and overall connectivity/performance. It's the default mode in AOSP and why it says it's recommended so people know which one to go back to if they have issues. We do not plan to change that.

Using our added settings ("4G only", "4G or 5G only" or "5G only") requires having VoLTE/VoNR for working calls, will lose connectivity if only 3G is available, etc. It is not the default for a reason, and we aren't giving a general recommendation that most people use the attack surface reduction feature. It is there for people who can accept the downsides for reduced attack surface. It may improve battery life but it can also reduce it, that depends a lot on the available connectivity.

AOSP recommends the default setting good reason. Many people already have issues with setting "4G only" and not understanding that lack of their carrier fully supporting it is why they don't have working calls anymore, etc. We don't want to make changes which would make this worse. The settings are for people who understand the consequences.

ryrona Every profile has their own VPN configuration for a reason. Owner user VPN is used for system services. If you want to keep things more separate, then you should use multiple profiles with their own VPNs configured. It can be the same VPN provider and the same account, or you can split it up at a higher expense. That is the way to deal with these things. Our network location service is not breaking the anonymity of using a VPN, it's just a typical location-based service, is opt-in and is very clear about the fact it will send location data (nearby Wi-Fi APs) to the enabled service. There will be offline support for people willing to download a database to their storage for the areas they need. What we've provided is already a huge step towards offline support due to how Apple's API is designed. You should look at how it works. It already calculates the position estimate locally based on the downloaded Wi-Fi AP data. It only needs the service to obtain the data. With offline support, it will have a local database to query for Wi-Fi APs and can use exactly the same code for calculating the position as it uses for the online mode without a local database. It even already implements a local in-memory cache with 15 minute expiry so it can work offline to an extent after it puts data in the cache.

VEECCdYKYi We've made it clear that we're making our own database based on Apple's data. Scraping Apple's data for Wi-Fi APs will take a lot of time and work. Making our own database and software for using it is a whole lot more work that's going to take a while. Providing offline support is a whole lot more work on top of that. We're working on that. We've said we're doing it.

ToughDBlue See above.

As for your first question, the GrapheneOS proxy gets the information and passes it to Apple's service so it acts as an intermediary in that sense. If you have no qualms about contacting Apple's service directly, you can choose to do so.

IamZorro You either need to have Wi-Fi enabled, or Wi-Fi scanning enabled. If you have Wi-Fi on, you don't need the scanning toggle. The scanning toggle just allows that to happen while Wi-Fi is off.

This release should reach Beta soon and should reach Stable tomorrow.

GrapheneOS version 2025030100 released:

https://grapheneos.org/releases#2025030100

See the linked release notes for a summary of the improvements over the previous release.